ANCP Migration Carrier Analysis Thomas Haag; Birgit Witschurke,

Slides:



Advertisements
Similar presentations
ANCP Best Practice–Adjacency Carrier Analysis Thomas Haag; Birgit Witschurke,
Advertisements

1 Introducing the Specifications of the Metro Ethernet Forum.
1 Internet Protocol Version 6 (IPv6) What the caterpillar calls the end of the world, nature calls a butterfly. - Anonymous.
PPPoE Last Update Copyright Kenneth M. Chipps Ph.D. 1.
OSI Model OSI MODEL.
1IETF-59 MANET WG Ad Hoc IP Address Autoconfiguration Jaehoon Jeong ETRI 3 rd February 2004 draft-jeong-adhoc-ip-addr-autoconf-01.txt.
© 2007 Pearson Education Inc., Upper Saddle River, NJ. All rights reserved.1 Computer Networks and Internets with Internet Applications, 4e By Douglas.
1 Introducing the Specifications of the Metro Ethernet Forum.
TRILL over IP draft-ietf-trill-over-ip-01.txt IETF 91, Honolulu Margaret Wasserman Donald Eastlake, Dacheng Zhang.
Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks ANCP WG IETF 70 – Vancouver draft-ietf-ancp-framework-04.txt.
Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks ANCP WG IETF 71 – Philadelphia draft-ietf-ancp-framework-05.txt.
(Business) Process Centric Exchanges
Jun Li DHCP Option for Access Network Information draft-lijun-dhc-clf-nass-option-01.
QUALCOMM Incorporated 1 Protocol Options for BSN- BSMCS Controller Interface Jun Wang, Kirti Gupta 05/16/2005 Notice: Contributors grant a free, irrevocable.
Chapter 9 Hardware Addressing and Frame Type Identification 1.Delivering and sending packets 2.Hardware addressing: specifying a destination 3. Broadcasting.
Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks IETF 66 - ANCP WG July 9-14, 2006 draft-ooghe-ancp-framework-00.txt.
- vertraulich / confidential IETF Meeting BoF, March 2006 Haag, Thomas, T-Systems ENPS PCT15th Seite 1, 22nd of March 2006 IETF BoF Session Layer.
WSON Summary Young Lee Document Relationships Information Gen-constraints Encode WSON Encode Signal Compatibility OSPF Gen-constraints.
Framework & Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks draft-ietf-ancp-framework-02.txt Presenter: Dong Sun.
Magnus Westerlund 1 The RTSP Core specification draft-ietf-mmusic-rfc2326bis-06.txt Magnus Westerlund Aravind Narasimhan Rob Lanphier Anup Rao Henning.
© NOKIAMSF Paris drieft-ietf-grmp-04.PPT / 28 March, 2000/ ADo page: 1 Review of draft-ietf-gsmp-04 Avri Doria, Nokia Fiffi Hellstrand, Nortel Networks.
A RTCP-based Retransmission Protocol for Unicast RTP Streaming Multimedia draft-podolsky-avt-rtprx-00.txt Matthew Podolsky, Koichi Yano, and Steven McCanne.
Access Node Control Protocol (ANCP) IETF 68, Prague Wojciech Dec Matthew Bocci
Layer 2 Control Protocol BoF (L2CP) IETF 65, Dallas, TX Wojciech Dec Matthew Bocci
Scope ancp-protocol-04 includes some ANCP extensions that support one multicast use case of ancp-framework NAS initiated ANCP Multicast Control lefaucheur-ancp-mc-extensions.
Extensions to PCEP for Hierarchical Path Computation Elements PCE draft-zhang-pcep-hierarchy-extensions-00 Fatai Zhang Quintin Zhao.
TSG-A WG4 TITLE: GRE L2TPv3 Comparison SOURCE:
OSI Model OSI MODEL. Communication Architecture Strategy for connecting host computers and other communicating equipment. Defines necessary elements for.
OSI Model OSI MODEL.
draft-jounay-pwe3-dynamic-pw-update-00.txt IETF 70 PWE3 Working Group
FILS Reduced Neighbor Report
BGP Flexible Communities
Chapter 19 Network Layer Protocols
PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt)
IP - The Internet Protocol
MPLS-TP Fault Management Draft draft-boutros-mpls-tp-fault-01
PANA Issues and Resolutions
20th CJK UNIOT-WG (Standardization of Mobile IPTV in ITU-T)
LMP Behavior Negotiation
ERP extension for EAP Early-authentication Protocol (EEP)
DEPARTMENT OF COMPUTER SCIENCE
Sanjay Wadhwa Juniper Networks
Sanjay Wadhwa Juniper Networks
Switched Multi-megabit Data Service (SMDS)
OSPF Extensions for ASON Routing draft-ietf-ccamp-gmpls-ason-routing-ospf-03.txt IETF67 - Prague - Mar’07 Dimitri.
IP - The Internet Protocol
RTCWeb Data Channel Management
IP - The Internet Protocol
Guide to TCP/IP Fourth Edition
Chapter 11 Data Link Control (DLC)
Zhenbin Li, Shunwan Zhuang Huawei Technologies
draft-ipdvb-sec-01.txt ULE Security Requirements
IP - The Internet Protocol
FILS Reduced Neighbor Report
Robert Moskowitz, Verizon
STA wake up using BSS Parameter Update Counter
draft-ggalimbe-ccamp-flexigrid-carrier-label-02
Chapter 15. Internet Protocol
OSI Model OSI MODEL.
IP - The Internet Protocol
IP - The Internet Protocol
Extended BFD draft-mirmin-bfd-extended
draft-liu-pim-mofrr-tilfa-00
Reducing Overhead in Active Scanning
Editors: Bala’zs Varga, Jouni Korhonen
Reducing Overhead in Active Scanning
IPv6 Current version of the Internet Protocol is Version 4 (v4)
E. Bellagamba, Ericsson P. Sköldström, Acreo D. Ward, Juniper
DetNet Architecture Updates
Presentation transcript:

ANCP Migration Carrier Analysis Thomas Haag; Birgit Witschurke,

27th July 2009IETF ANCP Working Group2 ANCP Migration  History  Known Codes/ Implementations (Examples)  Identified facts from documents/specifications  ANCP & Versioning - Draft-ietf-ancp-protocol06; Chapter 5  Outlook for future used TLVs  Use Cases  Recommendation

27th July 2009IETF ANCP Working Group3 ANCP Migration 1. History:  In 2006 ancp protocol work started.  In the meantime first code was provided by developing companies in order to deliver code for experimental field usage. Derived from that code first codes were implemented in equipment for first rollout in parallel in order to meet time to market requirements.  In the meantime IETF and BBF progressed layer 2 control ; In 12/2008 BBF finished “Layer 2 Control Mechanism, TR-147”  In 03/2009 BBF started Layer 2 Control work again in order to cover unconsidered use cases

27th July 2009IETF ANCP Working Group4 ANCP Migration -Known Codes/ Implementations 1/2

27th July 2009IETF ANCP Working Group5 ANCP Migration -Known Codes/ Implementations 2/2

27th July 2009IETF ANCP Working Group6 ANCP Migration Identified facts from documents/specifications  Introduction “chapter 1, ancp Framework”:  “The requirements spelled out in this document are based on the work that is performed by the Broadband Forum ([TR-147]).”  BBF TR-147 protocol requirements:  [R-24] The Control Protocol MUST have an Adjacency establishment sequence to inform each peer about the protocol version and control capabilities supported (Access Node, BNG) and negotiate a common subset.  [R-25] The Control Protocol MUST provide versioning support in order to allow different protocol versions to operate in the network at the same time (independently).

27th July 2009IETF ANCP Working Group7 ANCP Migration–ANCP Versioning & Draft-ietf-ancp- protocol06; Chapter 5 5. Access Node Control Protocol (ANCP) ANCP uses a subset of GSMPv3 messages described in [RFC3292] to implement currently defined use-cases. GSMPv3 general message format, used by all GSMP messages other than adjacency protocol messages, is defined in section of GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format. The modified GSMPv3 message format is defined as follows: | Vers | Sub | Message Type | Result| Code | | Partition ID | Transaction Identifier | |I| SubMessage Number | Length | | | ~ Message Payload ~ | | Figure 6: Modified GSMPv3 message format

27th July 2009IETF ANCP Working Group8 5. Access Node Control Protocol (ANCP) (cont.) The 8-bit version field in the base GSMPv3 message header is split into two 4 bit fields for carrying the version and a sub-version of the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP protocol. An ANCP implementation SHOULD always set the version field to 3, and the sub-version field to 1. The Result field in the message header has been modified to be 4 bits long, and the Code field to be 12 bits long. Version: The version number of the GSMP protocol being used in this session. ANCP uses version 3. Sub-Version: The sub-version number of the GSMP protocol being used in this session. ANCP uses sub-version 1 of the GSMP protocol. ANCP Migration–ANCP Versioning & Draft-ietf-ancp- protocol06; Chapter 5

27th July 2009IETF ANCP Working Group9 Result:  version field (chapter 5) belongs only to GSMP version used for ancp.  Subversion field is set fix to “1” Consequence: As defined ANCP uses a subset of GSMP but keeps these fields which are fix set to GSMPv3 Subversion 1. But theses fields are not used to distinguish between different ANCP implementation versions such as already in place based on e.g. protocol draft 00, 01, , RFC-Version ANCP Migration–ANCP Versioning & Draft-ietf-ancp- protocol06; Chapter 5

27th July 2009IETF ANCP Working Group10 ANCP Migration - Use Case - Today draft-ietf-ancp-protocol- 02.txt draft-ietf-ancp-protocol- 04.txt draft-wadhwa-gsmp- l2control-configuration- 01.txt draft-ietf-ancp-protocol- ??.txt BRAS AN 3 AN 2 AN 1 Multicast: new sub TLV Partition ID: changed from „0“ to „free configurable“ Changed Sub-TLVs DSL Line Attributes = 0x04 OldDSL-Type = 0x90 NewDSL-Type = 0x91 OAM-Loopback-Test-Parameter = 0x07 Parameter length from 8 auf 4 Byte reduced Capability Negotiation Use Case-Topology Discovery - OAM -Multicast -Line Config How to handle different versions? e.g. Version control

27th July 2009IETF ANCP Working Group11 ANCP Migration - Outlook for future used TLVs Source: draft-ietf-ancp-mc-extensions- 00.txt Chapter 4.1. Provisioning Message [Editor's Note: A generic mechanism should be defined in ancp-proto to deal with incorrect/invalid Provisioning message. This should include an error code for the AN to indicate that it does not know a given TLV and does not support the corresponding capability, and an error code for the AN to indicate that a given TLV and its corresponding capabilities have been "negotiated out" during the Capability negotiation phase. The present document can indicate that (i) the 1st error code can be used when Provisioning message contain a multicast related TLV but the AN does not support it and (ii) the 2nd error code can be used when Bandwidth- delegation-Control TLV indicates "active" but Bandwidth Delegation is not part of the negotiated multicast capabilities].

27th July 2009IETF ANCP Working Group12 ANCP Migration - Outlook for future used TLVs Source: draft-ietf-ancp-protocol06.txt: Chapter Line configuration „In future, more TLVs MAY be defined for individual service attributes of a DSL line (e.g. rates, interleaving delay, multicast channel entitlement access-list etc)”

27th July 2009IETF ANCP Working Group13 ANCP Migration - Outlook for future used TLVs - conclusion  Given references show that ancp work is an open work which provides flexibility for future development. IETF should take care about the facts that scenarios may occur that network elements may support the same use case per capability negotiation but supporting different TLV definitions.  From a carrier point of view a mechanism should be defined to prevent, that inconsistency due to different protocol versions caused by TLV interpretations, error code settings may exist.

27th July 2009IETF ANCP Working Group14 ANCP Migration - Use Case - Future -RFC ancp-protocol- 0x.txt RFC-ancp-protocol- 0x.txt & New Use Cases RFC ancp-protocol-0x.txt & MC extensions RFC ancp-protocol-0x.txt BRAS AN 4 AN 2 AN 1 New Use Case & TLV expected New Sub TLV expected Capability Negotiation Use Case-Topology Discovery - OAM -Multicast -Line Config How to handle different versions? e.g. Version control RFC ancp-protocol-0x.txt & Line Config extensions AN 3 New Sub TLV expected

27th July 2009IETF ANCP Working Group15 Ad hoc four options could solve this issue: OptionsDescriptionFeasibilityRecommendatio n Option 1: use the sub version field for ANCP - Versioning (because it is derived from GSMP but not needed any more for ANCP purpose) Using ancp framing provides capability of TLV/use case independent information exchange. Option 2: define a new field or TLV for Version purpose Inconsistency with protocol architecture because of use case specific on going TLV definitions Option 3: Using capability negotiationOnly per use case Not per ANCP SW Version Option4Version detection based on TLV structure/pattern Very complex due to upcoming TLVs and Sub TLVs ANCP Migration - Recommendation

Thank You!