1. ANCP Migration Carrier Analysis Thomas Haag; haagt@telekom.de Birgit Witschurke, b.witschurke@telekom.de

2. 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

3. 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

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

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

6. 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).

7. 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 3.1.1 of GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format. The modified GSMPv3 message format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Modified GSMPv3 message format

8. 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

9. 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, 02....06, RFC-Version ANCP Migration–ANCP Versioning & Draft-ietf-ancp- protocol06; Chapter 5

10. 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

11. 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].

12. 27th July 2009IETF ANCP Working Group12 ANCP Migration - Outlook for future used TLVs Source: draft-ietf-ancp-protocol06.txt: Chapter 5.4.3 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)”

13. 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.

14. 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

15. 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

16. Thank You!