draft-ietf-ancp-protocol-13.txt   draft-ietf-ancp-protocol-14.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track J. Moisand Intended status: Standards Track J. Moisand
Expires: July 8, 2011 Juniper Networks Expires: July 15, 2011 Juniper Networks
T. Haag T. Haag
Deutsche Telekom Deutsche Telekom
N. Voigt N. Voigt
Nokia Siemens Networks Nokia Siemens Networks
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
January 4, 2011 January 11, 2011
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-13 draft-ietf-ancp-protocol-14
Abstract Abstract
This document describes the Access Node Control Protocol (ANCP). This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in
a multi-service reference architecture in order to perform QoS- a multi-service reference architecture in order to perform QoS-
related, service-related and subscriber-related operations. Use related, service-related and subscriber-related operations. Use
cases for ANCP are documented in RFC 5851. As well as describing the cases for ANCP are documented in RFC 5851. As well as describing the
base ANCP protocol, this document specifies capabilities for Digital base ANCP protocol, this document specifies capabilities for Digital
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 8, 2011. This Internet-Draft will expire on July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 48 skipping to change at page 5, line 48
Figure 1: Architectural Context For the Access Node Control Protocol Figure 1: Architectural Context For the Access Node Control Protocol
At various points in this document, information flows between the At various points in this document, information flows between the
control applications and ANCP are described. The purpose of such control applications and ANCP are described. The purpose of such
descriptions is to clarify the boundary between this specification descriptions is to clarify the boundary between this specification
and, for example, [TR-147]. There is no intention to place limits on and, for example, [TR-147]. There is no intention to place limits on
the degree to which the control application and the protocol the degree to which the control application and the protocol
implementation are integrated. implementation are integrated.
This specification specifies ANCP transport over TLS/TCP/IP. TCP This specification specifies ANCP transport over TCP/IP. TCP
encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. The encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. The
alternative GSMPv3 encapsulation directly over Ethernet and ATM as alternative GSMPv3 encapsulation directly over Ethernet and ATM as
defined in [RFC3293] is not considered for ANCP. defined in [RFC3293] is not considered for ANCP.
The organization of this document is as follows: The organization of this document is as follows:
o The next two sub-sections introduce some terminology that will be o The next two sub-sections introduce some terminology that will be
useful in understanding the rest of the document. useful in understanding the rest of the document.
o Section 2 provides a description of the access networks within o Section 2 provides a description of the access networks within
skipping to change at page 19, line 40 skipping to change at page 19, line 40
o Action RECOMMENDED for the receiving ANCP agent o Action RECOMMENDED for the receiving ANCP agent
In addition to any suggested action in the text which follows, the In addition to any suggested action in the text which follows, the
Code value SHOULD be logged in a MIB. Where an action includes Code value SHOULD be logged in a MIB. Where an action includes
resending of a request, a given request SHOULD NOT be re-sent more resending of a request, a given request SHOULD NOT be re-sent more
than once. than once.
ANCP agents MAY use any of the Code values specified in the IANA ANCP agents MAY use any of the Code values specified in the IANA
registry "Global Switch Management Protocol version 3 (GSMPv3) registry "Global Switch Management Protocol version 3 (GSMPv3)
Failure Response Message Name Space" if they appear applicable. In Failure Response Message Name Space" if they appear applicable. In
particular, the values 2, 3, 4, 6, 7, and 19 appear to be reusable particular, the values 2, 6, 7, and 19 appear to be reusable and are
and are therefore documented below along with a few new ANCP-specific therefore documented below along with a few new ANCP-specific values.
values. Values 30 and 31 are also reusable, but are more Values 30 and 31 are also reusable, but are more appropriately
appropriately documented in a multicast extension document. documented in a multicast extension document.
Code value: 2 Code value: 2
* One-line description: Invalid request message * One-line description: Invalid request message
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: The request was a properly formed message * Further description: The request was a properly formed message
which violates the protocol through its timing or direction of which violates the protocol through its timing or direction of
transmission. The most likely reason for this outcome in the transmission. The most likely reason for this outcome in the
skipping to change at page 27, line 33 skipping to change at page 27, line 33
shown in Figure 8. Support of the Provisioning message is OPTIONAL shown in Figure 8. Support of the Provisioning message is OPTIONAL
unless the ANCP agent claims support for a capability that requires unless the ANCP agent claims support for a capability that requires
its use. its use.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of the Provisioning Message Figure 8: Format of the Provisioning Message
The message header field settings given below are REQUIRED in the The message header field settings given below are REQUIRED in the
skipping to change at page 29, line 10 skipping to change at page 29, line 10
receiver MAY record the information contained in the Status-Info TLV receiver MAY record the information contained in the Status-Info TLV
for management use. for management use.
The format of the Generic Response message is shown in Figure 9 The format of the Generic Response message is shown in Figure 9
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 3.2) | | TCP/IP Encapsulating Header (Section 3.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header | | ANCP General Message Header |
+ (Section 3.6.1) + + (Section 3.6.1) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access line identifying TLV(s) | | Access line identifying TLV(s) |
+ (copied from original request) + + (copied from original request) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV | | Status-Info TLV |
~ (Section 6.2.3) ~ ~ (Section 4.5) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this NOTE: TLVs MAY be in a different order from what is shown in this
figure. figure.
Figure 9: Structure of the Generic Response Message Figure 9: Structure of the Generic Response Message
This document specifies the following header fields. The remaining This document specifies the following header fields. The remaining
fields in the ANCP general message header MUST be set as specified in fields in the ANCP general message header MUST be set as specified in
skipping to change at page 52, line 33 skipping to change at page 52, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Reserved | |x|x|x|x|x|x|x|x| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access line identifying TLV(s) ~ ~ Access line identifying TLV(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Line configuration TLVs ~ ~ Line configuration TLV(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: TLVs MAY be in a different order from what is shown in this NOTE: TLVs MAY be in a different order from what is shown in this
figure. figure.
Figure 18: Port Management Message For DSL Line Configuration Figure 18: Port Management Message For DSL Line Configuration
See Section 3.6 for a description of the ANCP general message header. See Section 3.6 for a description of the ANCP general message header.
The Message Type field MUST be set to 32. The 12 bit Code field MUST The Message Type field MUST be set to 32. The 12 bit Code field MUST
be set to 0. The 4 bit Result field MUST be set to either 1 (NAck) be set to 0. The 4 bit Result field MUST be set to either 1 (NAck)
or 2 (AckAll), as determined by policy on the NAS. The 24-bit or 2 (AckAll), as determined by policy on the NAS. The 24-bit
Transaction Identifier field MUST be set to a positive value. Other Transaction Identifier field MUST be set to a positive value. Other
fields in the general header MUST be set as described in Section 3.6. fields in the general header MUST be set as described in Section 3.6.
The Port Management message format defined in [RFC3292] has been As with the Port Up and Port Down messages described above, the Port
modified to contain additional data at the end of the message. Also, Management message format defined in [RFC3292] has been modified to
the original two byte Function field has been modified to contain one contain additional data in an "extension block" at the end of the
byte for the Function field indicating a specific action to be taken message. Also, the original two byte Function field has been
by the recipient of the message, and one byte for X-Function field, modified to contain one byte for the Function field indicating a
which further qualifies the action specified in the Function field. specific action to be taken by the recipient of the message, and one
Any Function specific data MUST be carried in TLVs in the extension byte for X-Function field, which further qualifies the action
block. specified in the Function field. Any Function specific data MUST be
carried in TLVs in the extension block.
The Port, Port Session Number, and Event Sequence Number fields are The Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Line Configuration capability. The handling of not used by the DSL Line Configuration capability. The handling of
unused/reserved fields is described in Section 3.4. unused/reserved fields is described in Section 3.4.
The remaining message fields are described as follows: The remaining message fields are described as follows:
R Flag: not used by ANCP. R Flag: not used by ANCP.
Additional Port Management flags: the flag bits marked 'x' following Additional Port Management flags: the flag bits marked 'x' following
the R flag are not used by ANCP. the R flag are not used by ANCP.
Duration: not used for DSL line configuration. Duration: not used for DSL line configuration.
Function: action to be performed. For line configuration, Function Function: action to be performed. For line configuration, Function
MUST be set to 8 (Configure Connection Service Data). This action MUST be set to 8 (Configure Connection Service Data). This action
type requests the Access Node (i.e., DSLAM) to apply service type requests the Access Node (i.e., DSLAM) to apply service
configuration data contained in the extension value (TLVs) to the configuration data contained in the line configuration TLVs to the
DSL line (identified by one of the TLVs in the extension value). DSL line designated by the access line identifying TLVs.
X-Function: qualifies the action set by Function. For DSL line X-Function: qualifies the action set by Function. For DSL line
configuration, this field MUST be set to 0. configuration, this field MUST be set to 0.
Event Flags: not used by ANCP. Event Flags: not used by ANCP.
Flow Control Flags: not used by ANCP. Flow Control Flags: not used by ANCP.
Extension Flags: the flag bits denoted by 'x' before the Message Extension Flags: the flag bits denoted by 'x' before the Message
Type field are reserved for future use. Type field are reserved for future use.
 End of changes. 12 change blocks. 
23 lines changed or deleted 24 lines changed or added

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