draft-ietf-ancp-protocol-16.txt   draft-ietf-ancp-protocol-17.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: October 20, 2011 Juniper Networks Expires: October 28, 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
April 18, 2011 April 26, 2011
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-16 draft-ietf-ancp-protocol-17
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
Subscriber Line (DSL) topology discovery, line configuration, and Subscriber Line (DSL) topology discovery, line configuration, and
remote line connectivity testing. The design of ANCP allows for remote line connectivity testing. The design of ANCP allows for
protocol extensions in other documents if they are needed to support protocol extensions in other documents if they are needed to support
other use cases and other access technologies. other use cases and other access technologies.
ANCP is based on GSMPv3 (RFC 3292), but with many modifications and ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
extensions, to the point that the two protocols are not extensions, to the point that the two protocols are not
interoperable. interoperable. For this reason, ANCP was assigned a separate version
number to distinguish it.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 October 20, 2011.
This Internet-Draft will expire on October 28, 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 3, line 23 skipping to change at page 3, line 23
2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10 2.2. Ethernet-Based Broadband Aggregation . . . . . . . . . . . 10
3. Access Node Control Protocol -- General Aspects . . . . . . . 11 3. Access Node Control Protocol -- General Aspects . . . . . . . 11
3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11 3.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 11
3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11 3.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12 3.3. Encoding of Text Fields . . . . . . . . . . . . . . . . . 12
3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12 3.4. Treatment of Reserved and Unused Fields . . . . . . . . . 12
3.5. The ANCP Adjacency Protocol . . . . . . . . . . . . . . . 13 3.5. The ANCP Adjacency Protocol . . . . . . . . . . . . . . . 13
3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13 3.5.1. ANCP Adjacency Message Format . . . . . . . . . . . . 13
3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 19 3.5.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 19
3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 29 3.6. ANCP General Message Formats . . . . . . . . . . . . . . . 29
3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 29 3.6.1. The ANCP Message Header . . . . . . . . . . . . . . . 30
3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 36 3.6.2. The ANCP Message Body . . . . . . . . . . . . . . . . 36
3.7. General Principles for the Design of ANCP Messages . . . . 37 3.7. General Principles for the Design of ANCP Messages . . . . 37
4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 38 4. Generally Useful ANCP Messages and TLVs . . . . . . . . . . . 38
4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 38 4.1. Provisioning Message . . . . . . . . . . . . . . . . . . . 38
4.2. Generic Response Message . . . . . . . . . . . . . . . . . 39 4.2. Generic Response Message . . . . . . . . . . . . . . . . . 39
4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3. Target TLV . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 41 4.4. Command TLV . . . . . . . . . . . . . . . . . . . . . . . 42
4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 42 4.5. Status-Info TLV . . . . . . . . . . . . . . . . . . . . . 42
5. Introduction To ANCP Capabilities For Digital Subscriber 5. Introduction To ANCP Capabilities For Digital Subscriber
Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 43 Lines (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1. DSL Access Line Identification . . . . . . . . . . . . . . 44 5.1. DSL Access Line Identification . . . . . . . . . . . . . . 44
5.1.1. Control Context (Informative) . . . . . . . . . . . . 44 5.1.1. Control Context (Informative) . . . . . . . . . . . . 44
5.1.2. TLVs For DSL Access Line Identification . . . . . . . 45 5.1.2. TLVs For DSL Access Line Identification . . . . . . . 46
6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 48 6. ANCP Based DSL Topology Discovery . . . . . . . . . . . . . . 49
6.1. Control Context (Informative) . . . . . . . . . . . . . . 48 6.1. Control Context (Informative) . . . . . . . . . . . . . . 49
6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50 6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 50
6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 50 6.2.1. Protocol Requirements On the AN Side . . . . . . . . . 51
6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 50 6.2.2. Protocol Requirements On the NAS Side . . . . . . . . 51
6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 51 6.3. ANCP Port UP and Port DOWN Event Message Descriptions . . 51
6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 52 6.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 52 6.4.1. Procedures On the AN Side . . . . . . . . . . . . . . 53
6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 53 6.4.2. Procedures On the NAS Side . . . . . . . . . . . . . . 53
6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 53 6.5. TLVs For DSL Line Attributes . . . . . . . . . . . . . . . 54
6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 53 6.5.1. DSL-Line-Attributes TLV . . . . . . . . . . . . . . . 54
6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 54 6.5.2. DSL-Type TLV . . . . . . . . . . . . . . . . . . . . . 54
6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 54 6.5.3. Actual-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55
6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 54 6.5.4. Actual-Net-Data-Rate-Downstream TLV . . . . . . . . . 55
6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55 6.5.5. Minimum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 55
6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 55 6.5.6. Minimum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56
6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 55 6.5.7. Attainable-Net-Data-Rate-Upstream TLV . . . . . . . . 56
6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 55 6.5.8. Attainable-Net-Data-Rate-Downstream TLV . . . . . . . 56
6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 56 6.5.9. Maximum-Net-Data-Rate-Upstream TLV . . . . . . . . . . 56
6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56 6.5.10. Maximum-Net-Data-Rate-Downstream TLV . . . . . . . . . 56
6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 56 6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV . . . . . 57
6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 56 6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV . . . . 57
6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 57 6.5.13. Maximum-Interleaving-Delay-Upstream TLV . . . . . . . 57
6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 57 6.5.14. Actual-Interleaving-Delay-Upstream TLV . . . . . . . . 57
6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 57 6.5.15. Maximum-Interleaving-Delay-Downstream TLV . . . . . . 58
6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 57 6.5.16. Actual-Interleaving-Delay-Downstream . . . . . . . . . 58
6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 57 6.5.17. DSL-Line-State TLV . . . . . . . . . . . . . . . . . . 58
6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 58 6.5.18. Access-Loop-Encapsulation TLV . . . . . . . . . . . . 58
7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 59 7. ANCP based DSL Line Configuration . . . . . . . . . . . . . . 60
7.1. Control Context (Informative) . . . . . . . . . . . . . . 59 7.1. Control Context (Informative) . . . . . . . . . . . . . . 60
7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 60 7.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 61
7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 61 7.2.1. Protocol Requirements On the NAS Side . . . . . . . . 61
7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 61 7.2.2. Protocol Requirements On the AN Side . . . . . . . . . 61
7.3. ANCP Port Management (Line Configuration) Message 7.3. ANCP Port Management (Line Configuration) Message
Format . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 64 7.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 64
7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 64 7.4.1. Procedures On the NAS Side . . . . . . . . . . . . . . 64
7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 64 7.4.2. Procedures On the AN Side . . . . . . . . . . . . . . 64
7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 65 7.5. TLVs For DSL Line Configuration . . . . . . . . . . . . . 65
7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 65 7.5.1. Service-Profile-Name TLV . . . . . . . . . . . . . . . 65
8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 65 8. ANCP-Based DSL Remote Line Connectivity Testing . . . . . . . 65
8.1. Control Context (Informative) . . . . . . . . . . . . . . 65 8.1. Control Context (Informative) . . . . . . . . . . . . . . 65
8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 66 8.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 66
8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 66 8.2.1. Protocol Requirements On the NAS Side . . . . . . . . 66
8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 66 8.2.2. Protocol Requirements On the AN Side . . . . . . . . . 66
skipping to change at page 5, line 7 skipping to change at page 5, line 7
9.2.1. ANCP Message Type Registry . . . . . . . . . . . . . . 72 9.2.1. ANCP Message Type Registry . . . . . . . . . . . . . . 72
9.2.2. ANCP Result Code Registry . . . . . . . . . . . . . . 73 9.2.2. ANCP Result Code Registry . . . . . . . . . . . . . . 73
9.2.3. ANCP Port Management Function Registry . . . . . . . . 74 9.2.3. ANCP Port Management Function Registry . . . . . . . . 74
9.2.4. ANCP Technology Type Registry . . . . . . . . . . . . 75 9.2.4. ANCP Technology Type Registry . . . . . . . . . . . . 75
9.2.5. ANCP Command Code Registry . . . . . . . . . . . . . . 75 9.2.5. ANCP Command Code Registry . . . . . . . . . . . . . . 75
9.2.6. ANCP TLV Type Registry . . . . . . . . . . . . . . . . 75 9.2.6. ANCP TLV Type Registry . . . . . . . . . . . . . . . . 75
9.2.7. ANCP Capability Type Registry . . . . . . . . . . . . 77 9.2.7. ANCP Capability Type Registry . . . . . . . . . . . . 77
9.2.8. Joint GSMP / ANCP Version Registry . . . . . . . . . . 77 9.2.8. Joint GSMP / ANCP Version Registry . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 79
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
12.1. Normative References . . . . . . . . . . . . . . . . . . . 80 12.1. Normative References . . . . . . . . . . . . . . . . . . . 79
12.2. Informative References . . . . . . . . . . . . . . . . . . 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81
1. Introduction 1. Introduction
This draft defines a new protocol, the Access Node Control Protocol This draft defines a new protocol, the Access Node Control Protocol
(ANCP), to realize a control plane between a service-oriented layer 3 (ANCP), to realize a control plane between a service-oriented layer 3
edge device (the Network Access Server, NAS) and a layer 2 Access edge device (the Network Access Server, NAS) and a layer 2 Access
Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
perform operations related to quality of service (QoS), services, and perform operations related to quality of service (QoS), services, and
subscriptions. The requirements for ANCP and the context within subscriptions. The requirements for ANCP and the context within
which it operates are described in [RFC5851]. which it operates are described in [RFC5851].
skipping to change at page 14, line 44 skipping to change at page 14, line 44
Version (8 bits): ANCP version, which is subject to negotiation. Version (8 bits): ANCP version, which is subject to negotiation.
This is the key parameter by means of which ANCP messages can be This is the key parameter by means of which ANCP messages can be
distinguished from GSMP messages received over the same port. distinguished from GSMP messages received over the same port.
Message Type (8 bits): always has value 10 (adjacency protocol). Message Type (8 bits): always has value 10 (adjacency protocol).
Timer (8 bits): The Timer field is used to negotiate the timer value Timer (8 bits): The Timer field is used to negotiate the timer value
used in the adjacency protocol with the peer. The timer specifies used in the adjacency protocol with the peer. The timer specifies
the nominal time between periodic adjacency protocol messages. It the nominal time between periodic adjacency protocol messages. It
is a constant for the duration of an ANCP session. The timer is a constant for the duration of an ANCP session. The Timer
field is specified in units of 100ms, with a default value of 250 field is specified in units of 100ms, with a default value of 250
(i.e., 25 seconds). (i.e., 25 seconds).
M-flag (one bit): used in the SYN message to prevent the NAS from M-flag (one bit): used in the SYN message to prevent the NAS from
synchronizing with another NAS, and the AN from synchronizing with synchronizing with another NAS, and the AN from synchronizing with
another AN. In the SYN message, always set to 1 by the NAS, and another AN. In the SYN message, always set to 1 by the NAS, and
to 0 by the AN. In other adjacency message types, always set to 0 to 0 by the AN. In other adjacency message types, always set to 0
by the sender and ignored by the receiver. by the sender and ignored by the receiver.
Code (7 bits): the adjacency protocol message type. It MUST have Code (7 bits): the adjacency protocol message type. It MUST have
skipping to change at page 16, line 19 skipping to change at page 16, line 19
1 - fixed partition request; 1 - fixed partition request;
2 - fixed partition assigned. 2 - fixed partition assigned.
PFlag (4 bits): used to indicate the type of partition request. PFlag (4 bits): used to indicate the type of partition request.
1 - new adjacency; 1 - new adjacency;
2 - recovered adjacency. 2 - recovered adjacency.
In case of a conflict between the peers' views of the value of
PFlag, the lower value is used.
Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is Sender Instance (24 bits): For the SYN, SYNACK, and ACK messages, is
the sender's instance number for the link to the peer. It is used the sender's instance number for the link to the peer. It is used
to detect when the link comes back up after going down or when the to detect when the link comes back up after going down or when the
identity of the entity at the other end of the link changes. The identity of the entity at the other end of the link changes. The
instance number is a 24-bit number that is guaranteed to be unique instance number is a 24-bit number that is guaranteed to be unique
within the recent past and to change when the link or node comes within the recent past and to change when the link or node comes
back up after going down. Zero is not a valid instance number. back up after going down. Zero is not a valid instance number.
For the RSTACK message, the Sender Instance field is set to the For the RSTACK message, the Sender Instance field is set to the
value of the Receiver Instance field from the incoming message value of the Receiver Instance field from the incoming message
that caused the RSTACK message to be generated. that caused the RSTACK message to be generated.
Partition ID (8 bits): field used to associate the message with a Partition ID (8 bits): field used to associate the message with a
specific partition of the AN. specific partition of the AN. The value of this field is
negotiated during the adjacency procedure. The AN makes the final
decision, but will consider a request from the NAS. If the AN
does not support partitions, the value of this field MUST be 0.
Otherwise, it MUST be non-zero.
Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages, Receiver Instance (24 bits): For the SYN, SYNACK, and ACK messages,
is what the sender believes is the current instance number for the is what the sender believes is the current instance number for the
link, allocated by the entity at the far end of the link. If the link, allocated by the entity at the far end of the link. If the
sender of the message does not know the current instance number at sender of the message does not know the current instance number at
the far end of the link, this field SHOULD be set to zero. For the far end of the link, this field SHOULD be set to zero. For
the RSTACK message, the Receiver Instance field is set to the the RSTACK message, the Receiver Instance field is set to the
value of the Sender Instance field from the incoming message that value of the Sender Instance field from the incoming message that
caused the RSTACK message to be generated. caused the RSTACK message to be generated.
skipping to change at page 19, line 38 skipping to change at page 19, line 52
3.5.2. ANCP Adjacency Procedures 3.5.2. ANCP Adjacency Procedures
3.5.2.1. Overview 3.5.2.1. Overview
The ANCP adjacency protocol operates symmetrically between the NAS The ANCP adjacency protocol operates symmetrically between the NAS
and the AN. In the absence of errors or race conditions, each peer and the AN. In the absence of errors or race conditions, each peer
sends a SYN message, receives a SYNACK message in acknowledgement, sends a SYN message, receives a SYNACK message in acknowledgement,
and completes the establishment of the adjacency by sending an ACK and completes the establishment of the adjacency by sending an ACK
message. Through this exchange, each peer learns the values of the message. Through this exchange, each peer learns the values of the
Name, Port, and Instance parameters identifying the other peer, and Name, Port, and Instance parameters identifying the other peer, and
the two peers negotiate the values of the Version and Partition ID the two peers negotiate the values of the Version, Timer, PFlag, and
parameters and the set of capabilities that the adjacency will Partition ID parameters and the set of capabilities that the
support. adjacency will support.
Once the adjacency has been established, its liveness is periodically Once the adjacency has been established, its liveness is periodically
tested. The peers engage in an ACK message exchange at a frequency tested. The peers engage in an ACK message exchange at a frequency
determined by the negotiated value of the Timer field. determined by the negotiated value of the Timer field.
If an inconsistency, loss of contact, or protocol violation is If an inconsistency, loss of contact, or protocol violation is
detected, the detecting peer can force a restart of the detected, the detecting peer can force a restart of the
synchronization process by sending an RSTACK message to the other synchronization process by sending an RSTACK message to the other
end. end.
skipping to change at page 24, line 25 skipping to change at page 24, line 41
2 - the value of Partition ID contained in this message is 2 - the value of Partition ID contained in this message is
assigned to the current partition. assigned to the current partition.
Settings by the NAS: Settings by the NAS:
0 - the NAS leaves the decision on partitioning to the AN 0 - the NAS leaves the decision on partitioning to the AN
(RECOMMENDED setting); (RECOMMENDED setting);
1 - the NAS requests that the AN use the value of Partition 1 - the NAS requests that the AN use the value of Partition
ID contained in this message for the current partition. The ID contained in this message for the current partition. The
NAS MUST be prepared to use whatever value it receives in a NAS MAY use this setting even if it has already received a
SYN or SYNACK message, even if this differs from the SYN message from the AN, provided that the AN has indicated
requested value. support for partitions. The NAS MUST be prepared to use
whatever value it receives in a subsequent SYN or SYNACK
message, even if this differs from the requested value.
PFlag: set to the mode of adjacency setup (new adjacency vs. PFlag: set to the mode of adjacency setup (new adjacency vs.
recovered adjacency) requested by the sender. Warning: setting recovered adjacency) requested by the sender. Warning: setting
PFlag=1 runs the risk of state mismatch because ANCP does not PFlag=1 runs the risk of state mismatch because ANCP does not
provide the means for the NAS to audit the current state of the provide the means for the NAS to audit the current state of the
AN. AN.
Sender Instance: set as described in Section 3.5.1. Sender Instance: set as described in Section 3.5.1.
Partition ID: MUST be set to 0 if PType=0, otherwise set to the Partition ID: MUST be set to 0 if PType=0, otherwise set to the
skipping to change at page 27, line 5 skipping to change at page 27, line 23
Sender Instance: MUST be set to the Receiver Instance value recorded Sender Instance: MUST be set to the Receiver Instance value recorded
as part of adjacency state. as part of adjacency state.
Receiver Instance: MUST be set to the Sender Instance value recorded Receiver Instance: MUST be set to the Sender Instance value recorded
as part of adjacency state. as part of adjacency state.
If the set of capabilities recorded in the adjacency state is empty, If the set of capabilities recorded in the adjacency state is empty,
then after sending the SYNACK the sender MUST raise an alarm to then after sending the SYNACK the sender MUST raise an alarm to
management, halt the adjacency procedure, and tear down the TCP management, halt the adjacency procedure, and tear down the TCP
session if it is not being used by anothewr adjacency. The sender session if it is not being used by another adjacency. The sender MAY
MAY also terminate the IPSec security association if no other also terminate the IPSec security association if no other adjacency
adjacency is using it. is using it.
3.5.2.4.2. Action By the Receiver 3.5.2.4.2. Action By the Receiver
As indicated by the state tables, the receiver of a SYNACK first As indicated by the state tables, the receiver of a SYNACK first
checks that the Receiver Name, Receiver Port, and Receiver Instance checks that the Receiver Name, Receiver Port, and Receiver Instance
values match the Sender Name, Sender Port, and Sender Instance values values match the Sender Name, Sender Port, and Sender Instance values
it sent in SYN message that is being acknowledged. The AN also it sent in SYN message that is being acknowledged. The AN also
checks that the PType and Partition ID match. If any of these checks checks that the PType and Partition ID match. If any of these checks
fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1. fail, the receiver sends an RSTACK as described in Section 3.5.2.6.1.
skipping to change at page 29, line 6 skipping to change at page 29, line 23
the same as the sender would send in a SYN message. The Message Type the same as the sender would send in a SYN message. The Message Type
MUST be 10, the M-flag MUST be 0, and Code MUST be 4 (RSTACK). MUST be 10, the M-flag MUST be 0, and Code MUST be 4 (RSTACK).
3.5.2.6.2. Action By the Receiver 3.5.2.6.2. Action By the Receiver
The receiver of an RSTACK MAY attempt to diagnose the problem which The receiver of an RSTACK MAY attempt to diagnose the problem which
caused the RSTACK to be generated by comparing its own adjacency caused the RSTACK to be generated by comparing its own adjacency
state with the contents of the RSTACK. However, the primary purpose state with the contents of the RSTACK. However, the primary purpose
of the RSTACK is to trigger action as prescribed by Section 3.5.2.2. of the RSTACK is to trigger action as prescribed by Section 3.5.2.2.
3.5.2.7. Loss of Contact or Synchronization 3.5.2.7. Loss of Synchronization
Subsequent to adjacency establishment, if the adjacency times out on Loss of synchronisation MAY be declared if after synchronisation is
either end, due to not receiving an adjacency message for a duration achieved:
of (3 * Timer value), all the state received from the ANCP peer
SHOULD be cleaned up, and the TCP connection SHOULD be closed if it
is not being used by another adjacency. If it is closed, the NAS
MUST continue to listen for new connection requests. The AN MUST try
to re-establish the TCP connection and both sides MUST attempt to re-
establish the adjacency once that connection has been reestablished.
After initial synchronization, if at any time a mismatch in adjacency o no valid ANCP messages are received in any period of time in
state is detected, the adjacency MUST be brought down (RSTACK MUST be excess of three times the value of the Timer field negotiated in
generated by the device detecting the mismatch), and synchronization the adjacency protocol messages, or
MUST be re-attempted.
o a mismatch in adjacency state is detected.
In either case the peer detecting the condition MUST send an RSTACK
to the other peer as directed in Section 3.5.2.6.1, in order to
initiate resynchronization.
While re-establishing synchronisation with a controller, a switch
SHOULD maintain its connection state, deferring the decision about
resetting the state until after synchronisation is re-established.
Once synchronisation is re-established the decision about resetting
the connection state SHOULD be made based on the negotiated value of
PFlag.
3.6. ANCP General Message Formats 3.6. ANCP General Message Formats
This section describes the general format of ANCP messages other than This section describes the general format of ANCP messages other than
the adjacency messages. See Figure 7 the adjacency messages. See Figure 7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result| Result Code | | Version | Message Type | Result| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 30, line 46 skipping to change at page 31, line 26
Result Code value and any diagnostic data contained in a Status- Result Code value and any diagnostic data contained in a Status-
Info TLV included in the response. Info TLV included in the response.
3.6.1.4. Result Code Field (12 bits) 3.6.1.4. Result Code Field (12 bits)
This field gives further information concerning the result in a This field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a response message. It is mostly used to pass an error code in a
failure response but can also be used to give further information in failure response but can also be used to give further information in
a success response message or an event message. In a request a success response message or an event message. In a request
message, the Result Code field is not used and MUST be set to 0x0 (No message, the Result Code field is not used and MUST be set to 0x0 (No
error). result).
A number of Result Code values are specified below. Specification of A number of Result Code values are specified below. Specification of
additional Result Code values in extensions or updates to this additional Result Code values in extensions or updates to this
document MUST include the following information: document MUST include the following information:
o Result Code value; o Result Code value;
o One-line description; o One-line description;
o Where condition detected: (control application or ANCP agent); o Where condition detected: (control application or ANCP agent);
skipping to change at page 31, line 28 skipping to change at page 32, line 7
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, a In addition to any suggested action in the text which follows, a
count of the number of times a given non-zero Result Code value was count of the number of times a given non-zero Result Code value was
received SHOULD be provided for management. Where an action includes received SHOULD be provided for management. 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.
This document specifies the following Result Code values. This document specifies the following Result Code values.
Result Code value: 2 Result Code value: 0x2
* 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
field will be a race condition. field will be a race condition.
skipping to change at page 32, line 5 skipping to change at page 32, line 31
Response message. Response message.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: The original * Action RECOMMENDED for the receiving ANCP agent: The original
request MAY be re-sent once only after a short delay. Inform request MAY be re-sent once only after a short delay. Inform
the control application with appropriate identification of the the control application with appropriate identification of the
failed transaction if the second attempt fails or no second failed transaction if the second attempt fails or no second
attempt is made. attempt is made.
Result Code value: 6 Result Code value: 0x6
* One-line description: One or more of the specified ports are * One-line description: One or more of the specified ports are
down down
* Where condition detected: control application * Where condition detected: control application
* Further description (if any): This Result Code value indicates * Further description (if any): This Result Code value indicates
a state mismatch between the NAS and AN control applications, a state mismatch between the NAS and AN control applications,
possibly due to a race condition. possibly due to a race condition.
skipping to change at page 32, line 29 skipping to change at page 33, line 6
Status-Info TLV encapsulating TLV(s) containing the line Status-Info TLV encapsulating TLV(s) containing the line
identifier(s) of the access lines that are not operational. identifier(s) of the access lines that are not operational.
* Target: control application at the peer that sent the original * Target: control application at the peer that sent the original
request request
* Action RECOMMENDED for the receiving ANCP agent: indicate the * Action RECOMMENDED for the receiving ANCP agent: indicate the
error and forward the line identifier(s) to the control error and forward the line identifier(s) to the control
application. application.
Result Code value: 19 Result Code value: 0x13
* One-line description: Out of resources * One-line description: Out of resources
* Where condition detected: ANCP protocol layer or control * Where condition detected: ANCP protocol layer or control
application application
* Further description: (e.g., memory exhausted, etc.). This * Further description: (e.g., memory exhausted, etc.). This
Result Code value MUST be reported only by the AN, and Result Code value MUST be reported only by the AN, and
indicates a condition that is probably unrelated to specific indicates a condition that is probably unrelated to specific
access lines (although it may be related to the specific access lines (although it may be related to the specific
skipping to change at page 33, line 10 skipping to change at page 33, line 36
* Action RECOMMENDED for the receiving ANCP agent: If the NAS * Action RECOMMENDED for the receiving ANCP agent: If the NAS
receives this Result Code value from multiple requests for the receives this Result Code value from multiple requests for the
same AN in a short interval, it SHOULD reduce the rate at which same AN in a short interval, it SHOULD reduce the rate at which
it sends requests in proportion to the rate at which requests it sends requests in proportion to the rate at which requests
are failing with Result Code = 19. It MAY retry individual are failing with Result Code = 19. It MAY retry individual
requests. If only a specific request is failing with Result requests. If only a specific request is failing with Result
Code = 19, the ANCP agent in the NAS MAY request the control Code = 19, the ANCP agent in the NAS MAY request the control
application to decompose the request into simpler components if application to decompose the request into simpler components if
this is possible. this is possible.
Result Code value: 81 Result Code value: 0x51
* One-line description: Request message type not implemented * One-line description: Request message type not implemented
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: This could indicate a mismatch in protocol * Further description: This could indicate a mismatch in protocol
version or capability state. It is also possible that support version or capability state. It is also possible that support
of a specific message is optional within some ANCP capability. of a specific message is optional within some ANCP capability.
* Required additional information in the response message: none, * Required additional information in the response message: none,
skipping to change at page 33, line 40 skipping to change at page 34, line 20
capabilities negotiated for the session, it MAY re-send the capabilities negotiated for the session, it MAY re-send the
message in case the message was corrupted in transit the first message in case the message was corrupted in transit the first
time. If that fails, and use of the message type cannot be time. If that fails, and use of the message type cannot be
avoided, the ANCP agent MAY reset the adjacency by sending an avoided, the ANCP agent MAY reset the adjacency by sending an
RSTACK adjacency message (Section 3.5.2.6.1) where PType is set RSTACK adjacency message (Section 3.5.2.6.1) where PType is set
to 0 and Sender and Receiver Name, Port, and Instance are taken to 0 and Sender and Receiver Name, Port, and Instance are taken
from recorded adjacency state. If a reset does not eliminate from recorded adjacency state. If a reset does not eliminate
the problem, the receiving ANCP agent SHOULD raise an alarm to the problem, the receiving ANCP agent SHOULD raise an alarm to
management and then cease to operate. management and then cease to operate.
Result Code value: 83 Result Code value: 0x53
* One-line description: Malformed message * One-line description: Malformed message
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: This could be the result of corruption in * Further description: This could be the result of corruption in
transit, or an error in implementation at one end or the other. transit, or an error in implementation at one end or the other.
* Required additional information in the response message: none, * Required additional information in the response message: none,
if the response message is of the same type as the request. As if the response message is of the same type as the request. As
specified in Section 4.2 if the response message is a Generic specified in Section 4.2 if the response message is a Generic
Response message. Response message.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: The request * Action RECOMMENDED for the receiving ANCP agent: The request
SHOULD be re-sent once to eliminate the possibility of in- SHOULD be re-sent once to eliminate the possibility of in-
transit corruption. transit corruption.
Result Code value: 84 Result Code value: 0x54
* One-line description: Mandatory TLV missing * One-line description: Mandatory TLV missing
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: none. * Further description: none.
* Required additional information in the response message: the * Required additional information in the response message: the
response message MUST contain a Status-Info message that response message MUST contain a Status-Info message that
encapsulates an instance of each missing mandatory TLV, where encapsulates an instance of each missing mandatory TLV, where
skipping to change at page 34, line 34 skipping to change at page 35, line 13
only the four-byte TLV header is present). only the four-byte TLV header is present).
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: resend the * Action RECOMMENDED for the receiving ANCP agent: resend the
message with the missing TLV(s), if possible. Otherwise, message with the missing TLV(s), if possible. Otherwise,
report the error to the control application with an indication report the error to the control application with an indication
of the missing information required to construct the missing of the missing information required to construct the missing
TLV(s). TLV(s).
Result Code value: 85 Result Code value: 0x55
* One-line description: Invalid TLV contents * One-line description: Invalid TLV contents
* Where condition detected: ANCP agent * Where condition detected: ANCP agent
* Further description: the contents of one or more TLVs in the * Further description: the contents of one or more TLVs in the
request do not match the specifications provided for the those request do not match the specifications provided for the those
TLVs. TLVs.
* Required additional information in the response message: the * Required additional information in the response message: the
response MUST contain a Status-Info TLV encapsulating the response MUST contain a Status-Info TLV encapsulating the
erroneous TLVs copied from the original request. erroneous TLVs copied from the original request.
* Target: ANCP agent at the peer that sent the original request * Target: ANCP agent at the peer that sent the original request
* Action RECOMMENDED for the receiving ANCP agent: correct the * Action RECOMMENDED for the receiving ANCP agent: correct the
error and resend the request, if possible. Otherwise, report error and resend the request, if possible. Otherwise, report
the error to the control application with an indication of the the error to the control application with an indication of the
erroneous information associated with the invalid TLV(s). erroneous information associated with the invalid TLV(s).
Result Code value: 1280 Result Code value: 0x500
* One-line description: One or more of the specified ports do not * One-line description: One or more of the specified ports do not
exist exist
* Where condition detected: control application * Where condition detected: control application
* Further description (if any): this may indicate a configuration * Further description (if any): this may indicate a configuration
mismatch between the AN and the NAS or AAA. mismatch between the AN and the NAS or AAA.
* Required additional information in the response message: if the * Required additional information in the response message: if the
skipping to change at page 51, line 24 skipping to change at page 52, line 14
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) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+--- Label (8 bytes, unused) ---+ ~ Unused (20 bytes) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)| | # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Access line identifying TLV(s) ~ ~ Access line identifying TLV(s) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 52, line 12 skipping to change at page 52, line 44
Figure 15: Format Of the ANCP Port Up and Port Down Event Messages Figure 15: Format Of the ANCP Port Up and Port Down Event Messages
For DSL Topology Discovery For DSL Topology Discovery
See Section 3.6.1 for a description of the ANCP general message See Section 3.6.1 for a description of the ANCP general message
header. The Message Type field MUST be set to 80 for Port Up, 81 for header. The Message Type field MUST be set to 80 for Port Up, 81 for
Port Down. The 12 bit Result Code field MUST be set to 0. The 4 bit Port Down. The 12 bit Result Code field MUST be set to 0. The 4 bit
Result field MUST be set to 0 (signifying Ignore). The 24-bit Result field MUST be set to 0 (signifying Ignore). The 24-bit
Transaction Identifier field MUST be set to 0. Other fields in the Transaction Identifier field MUST be set to 0. Other fields in the
general header MUST be set as described in Section 3.6. general header MUST be set as described in Section 3.6.
The Port, Port Session Number, and Event Sequence Number fields (32 The five word Unused field is a historical leftover. The handling of
bits each) are not used by the DSL Topology Discovery capability. unused/reserved fields is described in Section 3.4.
The 64-bit Label field is also unused, and MUST be treated as an
unused fixed 8-byte field. The handling of unused/reserved fields is
described in Section 3.4.
The remaining message fields belong to the "extension block", and are The remaining message fields belong to the "extension block", and are
described as follows: described as follows:
Extension Flags: The flag bits denoted by 'x' are currently Extension Flags: The flag bits denoted by 'x' are currently
unspecified and reserved. unspecified and reserved.
Message Type: Message Type has the same value as in the general Message Type: Message Type has the same value as in the general
header (i.e., 80 or 81). header (i.e., 80 or 81).
skipping to change at page 62, line 14 skipping to change at page 62, line 25
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) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (unused) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Unused (12 bytes) ~
| Port Session Number (unused) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number (unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Dur. (unused) | Function=8 | X-Function=0 | | Unused (2 bytes) | Function=8 | X-Function=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags (unused) | Flow Control Flags (unused) | | Unused (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 62, line 43 skipping to change at page 63, line 4
~ Line configuration TLV(s) ~ ~ 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 19: Port Management Message For DSL Line Configuration Figure 19: 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 Result Code The Message Type field MUST be set to 32. The 12 bit Result Code
field MUST be set to 0x0. The 4 bit Result field MUST be set to field MUST be set to 0x0. The 4 bit Result field MUST be set to
either 1 (NAck) or 2 (AckAll), as determined by policy on the NAS. either 1 (NAck) or 2 (AckAll), as determined by policy on the NAS.
The 24-bit Transaction Identifier field MUST be set to a positive The 24-bit Transaction Identifier field MUST be set to a positive
value. Other fields in the general header MUST be set as described value. Other fields in the general header MUST be set as described
in Section 3.6. in Section 3.6.
The Port, Port Session Number, and Event Sequence Number fields are The handling of the various unused/reserved fields is described in
not used by the DSL Line Configuration capability. The handling of 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.
Additional Port Management flags: the flag bits marked 'x' following
the R flag are not used by ANCP.
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 line configuration TLVs to the configuration data contained in the line configuration TLVs to the
DSL line designated by the access line identifying TLVs. 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.
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.
Message Type: Message Type has the same value as in the general Message Type: Message Type has the same value as in the general
header (i.e., 32). header (i.e., 32).
Reserved (16 bits): reserved for future use. Reserved (16 bits): reserved for future use.
# of TLVs: the number of TLVs that follow, not counting TLVs # of TLVs: the number of TLVs that follow, not counting TLVs
encapsulated within other TLVs. encapsulated within other TLVs.
skipping to change at page 73, line 42 skipping to change at page 73, line 42
o Target (control application or ANCP agent at the peer that sent o Target (control application or ANCP agent at the peer that sent
the original request); the original request);
o Action RECOMMENDED for the receiving ANCP agent o Action RECOMMENDED for the receiving ANCP agent
The values for Result Code are expressed in hexadecimal, and MAY The values for Result Code are expressed in hexadecimal, and MAY
range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is reserved for range from 0x0 to 0xFFFFFF. The range 0x0 to 0xFFF is reserved for
allocation by the criterion of IETF Review, as defined by [RFC5226]. allocation by the criterion of IETF Review, as defined by [RFC5226].
IANA SHOULD allocate new Result Code values from this range IANA SHOULD allocate new Result Code values from this range
sequentially beginning at 0x100. The range 0x1000 onwards SHALL be sequentially beginning at 0x100. The range 0x1000 onwards is
allocated by the criterion of Specification Required, as defined by allocated by the criterion of Specification Required, as defined by
[RFC5226]. IANA SHOULD allocate new Result Code values from this [RFC5226]. IANA SHOULD allocate new Result Code values from this
range sequentially beginning at 0x1000. The initial contents of the range sequentially beginning at 0x1000. The initial contents of the
ANCP Message Types registry are as follows: ANCP Message Types registry are as follows:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Result | One-line description | Reference | | Result | One-line description | Reference |
| Code | | | | Code | | |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| 0x0 | No result | RFCXXXX | | 0x0 | No result | RFCXXXX |
skipping to change at page 77, line 22 skipping to change at page 77, line 22
as defined by [RFC5226]. Values may range from 0 to 255. IANA as defined by [RFC5226]. Values may range from 0 to 255. IANA
SHOULD assign values sequentially beginning at 5. The specification SHOULD assign values sequentially beginning at 5. The specification
for a given capability MUST indicate the Technology Type value with for a given capability MUST indicate the Technology Type value with
which it is associated. The specification MUST further indicate which it is associated. The specification MUST further indicate
whether the capability is associated with any capability data. whether the capability is associated with any capability data.
Normally a capability is expected to be defined in the same document Normally a capability is expected to be defined in the same document
that specifies the implementation of that capability in protocol that specifies the implementation of that capability in protocol
terms. The initial entries in the ANCP capability registry are as terms. The initial entries in the ANCP capability registry are as
follows: follows:
+-------+-----------------+--------------+--------------+-----------+ +-------+------------------------+--------+-------------+-----------+
| Value | Capability Type | Technology | Capability | Reference | | Value | Capability Type Name | Tech | Capability | Reference |
| | Name | Type | Data | | | | | Type | Data? | |
+-------+-----------------+--------------+--------------+-----------+ +-------+------------------------+--------+-------------+-----------+
| 0 | Reserved | | | RFCXXXX | | 0 | Reserved | | | RFCXXXX |
| 1 | DSL Topology | 5 | No | RFCXXXX | | 1 | DSL Topology Discovery | 5 | No | RFCXXXX |
| | Discovery | | | | | 2 | DSL Line Configuration | 5 | No | RFCXXXX |
| 2 | DSL Line | 5 | No | RFCXXXX | | 3 | Reserved | | | RFCXXXX |
| | Configuration | | | | | 4 | DSL Line Testing | 5 | No | RFCXXXX |
| 3 | Reserved | | | RFCXXXX | +-------+------------------------+--------+-------------+-----------+
| 4 | DSL Line | 5 | None | RFCXXXX |
| | Testing | | | |
+-------+-----------------+--------------+--------------+-----------+
9.2.8. Joint GSMP / ANCP Version Registry 9.2.8. Joint GSMP / ANCP Version Registry
IANA is requested to create a new joint GSMP / ANCP Version registry. IANA is requested to create a new joint GSMP / ANCP Version registry.
Additions to this registry are by Standards Action as defined by Additions to this registry are by Standards Action as defined by
[RFC5226]. Values may range from 0 to 255. Values for the General [RFC5226]. Values may range from 0 to 255. Values for the General
Switch Management Protocol (GSMP) MUST be assigned sequentially Switch Management Protocol (GSMP) MUST be assigned sequentially
beginning with 4 for the next version. Values for the Access Network beginning with 4 for the next version. Values for the Access Network
Control Protocol (ANCP) MUST be assigned sequentially beginning with Control Protocol (ANCP) MUST be assigned sequentially beginning with
50 for the present version. The initial entries are as follows: 50 for the present version. The initial entries are as follows:
 End of changes. 51 change blocks. 
115 lines changed or deleted 106 lines changed or added

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