draft-ietf-ancp-protocol-07.txt   draft-ietf-ancp-protocol-08.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft J. Moisand Internet-Draft J. Moisand
Intended status: Standards Track S. Subramanian Intended status: Standards Track S. Subramanian
Expires: April 25, 2010 Juniper Networks Expires: May 13, 2010 Juniper Networks
T. Haag T. Haag
T-systems Deutsche Telekom
N. Voigt N. Voigt
Siemens Siemens
R. Maglione R. Maglione
Telecom Italia Telecom Italia
October 22, 2009 November 9, 2009
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-07 draft-ietf-ancp-protocol-08
Abstract
This document describes proposed extensions to the GSMPv3 protocol to
allow its use in a broadband environment, as a control plane between
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g.
NAS). These proposed extensions are required to realize a protocol
for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK].
The resulting protocol with the proposed extensions to GSMPv3
[RFC3292] is referred to as "Access Node Control Protocol" (ANCP).
This document currently focuses on specific use cases of access node
control mechanism for topology discovery, line configuration, and OAM
as described in ANCP framework document [ANCP-FRAMEWORK]. It is
intended to be augmented by additional protocol specification for
future use cases considered in scope by the ANCP charter.
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
in detail. Illustrative text for the use-cases is included here to
help the protocol implementer understand the greater context of ANCP
protocol interactions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 2, line 13
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes proposed extensions to the GSMPv3 protocol to described in the BSD License.
allow its use in a broadband environment, as a control plane between
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g.
NAS). These proposed extensions are required to realize a protocol
for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK].
The resulting protocol with the proposed extensions to GSMPv3
[RFC3292] is referred to as "Access Node Control Protocol" (ANCP).
This document currently focuses on specific use cases of access node
control mechanism for topology discovery, line configuration, and OAM
as described in ANCP framework document [ANCP-FRAMEWORK]. It is
intended to be augmented by additional protocol specification for
future use cases considered in scope by the ANCP charter.
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
in detail. Illustrative text for the use-cases is included here to
help the protocol implementer understand the greater context of ANCP
protocol interactions.
Table of Contents Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 4 1. Specification Requirements . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 6 3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 6
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 6 3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 6
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7 3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7
4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7 4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
4.4. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 13 4.4. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 13
5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 14 5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 14
5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 20 5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 20
5.2. ANCP Connection keepalive . . . . . . . . . . . . . . . . 21 5.2. ANCP Connection keepalive . . . . . . . . . . . . . . . . 21
5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 22 5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 22
5.4. GSMP Message Extensions for Access Node Control . . . . . 25 5.4. GSMP Message Extensions for Access Node Control . . . . . 25
5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 25 5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 25
5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 26 5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 27
5.4.3. Line Configuration Extensions . . . . . . . . . . . . 36 5.4.3. Line Configuration Extensions . . . . . . . . . . . . 37
5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 39 5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 40
5.4.5. Additional GSMP Extensions for future use cases . . . 42 5.4.5. Additional GSMP Extensions for future use cases . . . 43
5.4.5.1. General well known TLVs . . . . . . . . . . . . . 43 5.4.5.1. General well known TLVs . . . . . . . . . . . . . 44
5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 43 5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 44
5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 44 5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 45
5.4.5.1.3. Status-info TLV . . . . . . . . . . . . . . . 46 5.4.5.1.3. Status-info TLV . . . . . . . . . . . . . . . 47
5.4.5.2. Generic Response Message . . . . . . . . . . . . . 47 5.4.5.2. Generic Response Message . . . . . . . . . . . . . 48
5.5. ATM-specific considerations . . . . . . . . . . . . . . . 49 5.5. ATM-specific considerations . . . . . . . . . . . . . . . 50
5.6. Ethernet-specific considerations . . . . . . . . . . . . . 49 5.6. Ethernet-specific considerations . . . . . . . . . . . . . 50
6. Appendix: Handling of pre-RFC deployments of the ANCP 6. Appendix: Handling of pre-RFC deployments of the ANCP
protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
8. Security Considerations . . . . . . . . . . . . . . . . . . . 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 10.1. Normative References . . . . . . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . . 56 10.2. Informative References . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Specification Requirements 1. Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
DSL is a widely deployed access technology for Broadband Access for DSL is a widely deployed access technology for Broadband Access for
skipping to change at page 18, line 26 skipping to change at page 18, line 26
ANCP extensions defining new code values SHOULD use the range 0x0100 ANCP extensions defining new code values SHOULD use the range 0x0100
through 0x01ff for this purpose. through 0x01ff for this purpose.
The range of values from 256 to 4095 is reserved for IETF use. The range of values from 256 to 4095 is reserved for IETF use.
Partition ID: Partition ID:
This field is a 8 bit number which signifies a partition on the This field is a 8 bit number which signifies a partition on the
AN. AN.
AN and NAS MAY agree on the partition ID using one of the
following possible options:
1 - The partition ID could be configured on the AN and learnt by
NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as
part of configuring the neighbor information.
Transaction ID: Transaction ID:
24-bit field set by the sender of a Request message to associate a 24-bit field set by the sender of a Request message to associate a
Response message with the original Request message. The receiver Response message with the original Request message. The receiver
of a Request message reflects the transaction ID from the Request of a Request message reflects the transaction ID from the Request
message in the corresponding Response message. For event message in the corresponding Response message. For event
messages, the transaction identifier SHOULD be set to zero. The messages, the transaction identifier SHOULD be set to zero. The
Transaction Identifier is not used, and the field is not present, Transaction Identifier is not used, and the field is not present,
in the adjacency protocol. in the adjacency protocol.
skipping to change at page 58, line 5 skipping to change at page 59, line 5
Swami Subramanian Swami Subramanian
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Phone: Phone:
Fax: Fax:
Email: ssubramanian@juniper.net Email: ssubramanian@juniper.net
Thomas Haag Thomas Haag
T-systems Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64295
Germany
Phone: Phone: +49 6151 628 2088
Fax: Fax:
Email: thomas.haag@t-systems.com Email: haagt@telekom.de
Norber Voigt Norber Voigt
Siemens Siemens
Phone: Phone:
Fax: Fax:
Email: norbert.voigt@siemens.com Email: norbert.voigt@siemens.com
Roberta Maglione Roberta Maglione
Telecom Italia Telecom Italia
 End of changes. 12 change blocks. 
51 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/