draft-ietf-ancp-protocol-09.txt   draft-ietf-ancp-protocol-10.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 Juniper Networks
Expires: August 30, 2010 Juniper Networks Expires: January 12, 2011 T. Haag
T. Haag
Deutsche Telekom Deutsche Telekom
N. Voigt N. Voigt
Siemens Nokia Siemens Networks
R. Maglione T. Taylor, Ed.
Telecom Italia Huawei Technologies
February 26, 2010 July 11, 2010
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-09 draft-ietf-ancp-protocol-10
Abstract Abstract
This document describes proposed extensions to the GSMPv3 protocol to This document describes the Access Node Control Protocol (ANCP).
allow its use in a broadband environment, as a control plane between ANCP operates between a Network Access Server (NAS) and an Access
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
NAS). These proposed extensions are required to realize a protocol multi-service reference architecture in order to perform QoS-related,
for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. service-related and subscriber- related operations. Use cases for
The resulting protocol with the proposed extensions to GSMPv3 ANCP are documented in RFC 5851. As well as describing the base ANCP
[RFC3292] is referred to as "Access Node Control Protocol" (ANCP). protocol, this document specifies capabilities for Digital Subscriber
This document currently focuses on specific use cases of access node Line (DSL) topology discovery, line configuration, and line testing.
control mechanism for topology discovery, line configuration, and OAM The design of ANCP anticipates the specification in other documents
as described in ANCP framework document [ANCP-FRAMEWORK]. It is of extensions to the protocol to support additional ANCP protocol
intended to be augmented by additional protocol specification for capabilities covering other use cases and other technologies.
future use cases considered in scope by the ANCP charter.
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
in detail. Illustrative text for the use-cases is included here to extensions, to the point that the two protocols are not
help the protocol implementer understand the greater context of ANCP interoperable.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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 January 12, 2011.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 4 1. Specification Requirements . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 6 3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 7
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 6 3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 7
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7 3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 9
4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7 4. Access Node Control Protocol -- General Aspects . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 10
4.2. ANCP based Access Topology Discovery . . . . . . . . . . . 8 4.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12
4.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. ANCP Adjacency Message Format . . . . . . . . . . . . 12
4.3. ANCP based Line Configuration . . . . . . . . . . . . . . 10 4.3.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15
4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. ANCP General Message Formats . . . . . . . . . . . . . . . 16
4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 4.4.1. The ANCP Message Header . . . . . . . . . . . . . . . 17
4.4. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 13 4.4.2. The ANCP Message Body . . . . . . . . . . . . . . . . 20
4.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 13 5. ANCP Capabilities For Digital Subscriber Lines (DSL) . . . . . 22
5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 14 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 20 5.1.1. ATM-Specific Considerations . . . . . . . . . . . . . 22
5.2. ANCP Connection keepalive . . . . . . . . . . . . . . . . 21 5.1.2. Ethernet-Specific Considerations . . . . . . . . . . . 23
5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 22 5.2. ANCP Based DSL Topology Discovery . . . . . . . . . . . . 23
5.4. GSMP Message Extensions for Access Node Control . . . . . 25 5.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 25 5.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 24
5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 27 5.2.3. Specification of the ANCP DSL Topology Discovery
5.4.3. Line Configuration Extensions . . . . . . . . . . . . 37 Capability . . . . . . . . . . . . . . . . . . . . . . 25
5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 40 5.3. ANCP based DSL Line Configuration . . . . . . . . . . . . 39
5.4.5. Additional GSMP Extensions for future use cases . . . 43 5.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4.5.1. General well known TLVs . . . . . . . . . . . . . 44 5.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 40
5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 44 5.3.3. Specification of the ANCP DSL Line Configuration
5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 45 Capability . . . . . . . . . . . . . . . . . . . . . . 42
5.4.5.1.3. Status-info TLV . . . . . . . . . . . . . . . 47 5.4. ANCP Based DSL Line Testing Capability . . . . . . . . . . 46
5.4.5.2. Generic Response Message . . . . . . . . . . . . . 48 5.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 46
5.5. ATM-specific considerations . . . . . . . . . . . . . . . 50 5.4.2. Specification of the ANCP DSL Line Testing
5.6. Ethernet-specific considerations . . . . . . . . . . . . . 50 Capability . . . . . . . . . . . . . . . . . . . . . . 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 6. Additional ANCP Messages and TLVs . . . . . . . . . . . . . . 50
7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 6.1. Additional Messages and General Messaging Principles . . . 51
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 6.1.1. General Principles for the Design of ANCP Messages . 51
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.1.2. Provisioning Message . . . . . . . . . . . . . . . . . 51
9.1. Normative References . . . . . . . . . . . . . . . . . . . 56 6.1.3. Generic Response Message . . . . . . . . . . . . . . . 52
9.2. Informative References . . . . . . . . . . . . . . . . . . 56 6.2. TLVs For General Use . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2.1. Target TLV . . . . . . . . . . . . . . . . . . . . . . 54
6.2.2. Command TLV . . . . . . . . . . . . . . . . . . . . . 55
6.2.3. Status-Info TLV . . . . . . . . . . . . . . . . . . . 55
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 57
8. Security Considerations . . . . . . . . . . . . . . . . . . . 62
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10.1. Normative References . . . . . . . . . . . . . . . . . . . 62
10.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Changes from Version -09 to Version -10 . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
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 This draft defines a new protocol, the Access Node Control Protocol
Next Generation Networks. Several specifications like [TR-059], (ANCP), to realize a control plane between a service-oriented layer 3
[TR-058], [TR-092] describe possible architectures for these access edge device (the Network Access Server, NAS) and a layer 2 Access
networks. In the scope of these specifications are the delivery of Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
voice, video and data services. perform QoS-related, service- related and subscriber-related
operations. The protocol specification takes GSMPv3 [RFC3292] as a
starting point and specifies modifications and extensions to GSMPv3
to achieve ANCP requirements. Although ANCP is based on GSMPv3, the
two protocols are not interoperable.
When deploying value-added services across DSL access networks, This specification assumes ANCP transport over TCP/IP. TCP
special attention regarding quality of service and service control is encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. ANCP
required, which implies a tighter coordination between network encapsulation directly over Ethernet and ATM as defined for GSMPv3 in
elements in the broadband access network without burdening the OSS [RFC3293] is not considered.
layer.
This draft defines extensions and modifications to GSMPv3 (specified ANCP uses a subset of GSMPv3 messages, message content, and
in [RFC3292]) and certain new mechanisms to realize a control plane procedures to implement currently defined use cases. Additional ANCP
between a service-oriented layer 3 edge device (the NAS) and a layer2 messages, message content, and procedures are specified in this
Access Node (e.g. DSLAM) in order to perform QoS-related, service- document and may also be specified in other documents extending ANCP.
related and subscriber-related operations. The control protocol as a
result of these extensions and mechanisms is referred to as "Access
Node Control Protocol" (ANCP). Although ANCP is based on GSMPv3, it
is not interoperable with GSMPv3 defined in [RFC3292].
ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP The organization of this document is as follows:
encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3
encapsulation directly over Ethernet and ATM as defined in [RFC3293]
is not considered for ANCP.
ANCP uses a subset of GSMPv3 messages to implement currently defined o The next sub-section introduces some terminology that will be
use-cases. These relevant GSMPv3 messages are identified in section useful in understanding the rest of the document.
Section 5. GSMPv3 procedures with suitable extensions, as used by
ANCP, are described in sections Section 5.1, Section 5.2 and o Section 3 provides a description of the access networks within
Section 5.3. GSMPv3 general extensions and GSMPv3 message specific which ANCP will typically be deployed.
extensions required by ANCP are described in sub-sections of
Section 5.4. In addition to specifying extensions and modifications o Section 4 specifies generally applicable aspects of the ANCP
to relevant GSMP messages applicable to ANCP, this draft also defines protocol.
the usage of these messages by ANCP. Not all the fields in relevant
GSMP messages are used by ANCP. This draft indicates the value that o Section 5 describes and specifies the ANCP implementation of three
ANCP should set for the fields in these GSMP messages. capabilities applicable to the control of DSL access technology:
topology discovery, line configuration, and line testing (OAM).
o Section 6 provides a set of specifications expected to be useful
when defining extensions to the base protocol.
o Section 7 is the IANA Considerations section. Some codepoints are
added to existing GSMPv3 registries set up by [RFC3292], but a
number of new ANCP-specific registries are also defined.
o Section 8 addresses security considerations relating to ANCP, with
heavy reliance on [RFC5713].
RFC Editor's Note: the following paragraph should be deleted upon
publication.
At the time of writing of this specification some implementations of At the time of writing of this specification some implementations of
the ANCP protocol, based on pre-standards drafts are already the ANCP protocol based on pre-standards drafts are already
available. All these early-draft implementations use protocol available. These early-draft implementations use protocol version/
version/sub-version 3.1; standard ANCP protocol will use version/ sub-version 3.1. The standard ANCP protocol will use version/
sub-version 3.2 [Editor's note: sub-version needs to be changed from sub-version 3.2 Adopting a new sub-version value provides a way to
1 to 2 upon publication.] Adopting a new sub-version value provides disambiguate the two protocols and provides support for running a
a way to disambiguate the two protocols and allows for supporting pre-standard and a standards compliant ANCP implementation on any
running a pre-standard and a standards compliant ANCP implementation given ANCP node. The mechanism used to identify the protocol
on any given ANCP node. The mechanism used to identify the protocol
version/sub-version is part of the adjacency negotiation process and version/sub-version is part of the adjacency negotiation process and
it is described in details in Section 5.2. It is important to note it is described in detail in Section 4.3. NOTE: this mechanism does
that this mechanism does not guarantee backwards compatibility of the not guarantee backwards compatibility of the published ANCP
ANCP RFC specification to those early-draft implementations. specification with those early-draft implementations.
2.1. Terminology 2.1. Terminology
o Access Node (AN): Network device, usually located at a service Access Node (AN): Network device, usually located at a service
provider central office or street cabinet that terminates access provider central office or street cabinet that terminates access
(local) loop connections from subscribers. In case the access (local) loop connections from subscribers. In case the access
loop is a Digital Subscriber Line (DSL), the Access Node provides loop is a Digital Subscriber Line (DSL), the Access Node provides
DSL signal termination, and is referred to as DSL Access DSL signal termination, and is referred to as DSL Access
Multiplexer (DSLAM). Multiplexer (DSLAM).
o Network Access Server (NAS): Network element which aggregates Network Access Server (NAS): Network element which aggregates
subscriber traffic from a number of Access Nodes. The NAS is an subscriber traffic from a number of Access Nodes. The NAS is an
injection point for policy management and IP QoS in the access injection point for policy management and IP QoS in the access
network. IT is also referred to as Broadband Network Gateway network. It is also referred to as Broadband Network Gateway
(BNG) or Broadband Remote Access Server (BRAS). (BNG) or Broadband Remote Access Server (BRAS).
o Home Gateway (HGW): Network element that connects subscriber Home Gateway (HGW): Network element that connects subscriber devices
devices to the Access Node and the access network. In case of to the Access Node and the access network. In the case of DSL,
DSL, the Home Gateway is a DSL network termination that could the Home Gateway is a DSL network termination that could operate
either operate as a layer 2 bridge or as a layer 3 router. In the either as a layer 2 bridge or as a layer 3 router. In the latter
latter case, such a device is also referred to as a Routing case, such a device is also referred to as a Routing Gateway (RG).
Gateway (RG).
o Net Data Rate: portion of the total data rate of the DSL line that Net Data Rate: portion of the total data rate of the DSL line that
can be used to transmit actual user information (e.g. ATM cells can be used to transmit actual user information (e.g. ATM cells
of Ethernet frames). It excludes overhead that pertains to the of Ethernet frames). It excludes overhead that pertains to the
physical transmission mechanism (e.g. trellis coding in case of physical transmission mechanism (e.g. trellis coding in case of
DSL). This is defined in section 3.39 of ITU-T G.993.2. DSL). This is defined in section 3.39 of ITU-T G.993.2.
o DSL line (synch) rate: the total data rate of the DSL line, DSL line (synch) rate: the total data rate of the DSL line,
including the overhead attributable to the physical transmission including the overhead attributable to the physical transmission
mechanism. mechanism.
o DSL multi-pair bonding: method for bonding (or aggregating) DSL multi-pair bonding: method for bonding (or aggregating) multiple
multiple xDSL lines into a single bi-directional logical link, xDSL lines into a single bi-directional logical link, henceforth
henceforth referred to in this draft as "DSL bonded circuit". DSL referred to in this draft as "DSL bonded circuit". DSL "multi-
"multi-pair" bonding allows an operator to combine the data rates pair" bonding allows an operator to combine the data rates on two
on two or more copper pairs, and deliver the aggregate data rate or more copper pairs, and deliver the aggregate data rate to a
to a single customer. ITU-T recommendations G.998.1 and G.998.2 single customer. ITU-T recommendations G.998.1 and G.998.2
respectively describe ATM and Ethernet based multi-pair bonding. respectively describe ATM and Ethernet based multi-pair bonding.
Type-Length-Value (TLV): a data structure consisting of a sixteen-
bit type field, a sixteen-bit length field, and a variable-length
value field padded to the nearest 32-bit word boundary, as
described in Section 4.4.2. The value field of a TLV can contain
other TLVs. An IANA registry is maintained for values of the ANCP
TLV Type field.
ANCP Protocol Capability: A detailed specification of ANCP messages,
message content, and procedures required to implement a specific
use case or set of use cases. ANCP capabilities may be specific
to one access technology or technology independent. The set of
capabilities applicable to a given ANCP session are negotiated
during session startup.
ANCP session (adjacency): A session between a NAS and an Access
Node, beginning with the initiation of the transport connection by
the AN, passing through adjacency negotiation, discovery and
provisioning stages, and continuing with service control and
possible OAM operations until the transport connection is
terminated. There may be more than one ANCP session active
between the NAS and a given AN due to partitioning.
3. Broadband Access Aggregation 3. Broadband Access Aggregation
3.1. ATM-based broadband aggregation 3.1. ATM-based broadband aggregation
End to end DSL network consists of network and application service The end to end DSL network consists of network and application
provider networks (NSP and ASP networks), regional/access network, service provider networks (NSP and ASP networks), regional/access
and customer premises network. Figure 1 shows ATM broadband access network, and customer premises network. Figure 1 shows ATM broadband
network components. access network components.
The Regional/Access Network consists of the Regional Network, Network The Regional/Access Network consists of the Regional Network, Network
Access Server, and the Access Network as show in Figure 1. Its Access Server, and the Access Network as shown in Figure 1. Its
primary function is to provide end-to-end transport between the primary function is to provide end-to-end transport between the
customer premises and the NSP or ASP. The Access Node terminates the customer premises and the NSP or ASP. The Access Node terminates the
DSL signal. It could consist of DSLAM in the central office, or DSL signal. It may be in the form of a DSLAM in the central office,
remote DSLAM, or a Remote Access Multiplexer (RAM). Access node is or a remote DSLAM, or a Remote Access Multiplexer (RAM). The access
the first point in the network where traffic on multiple DSL lines node is the first point in the network where traffic on multiple DSL
will be aggregated onto a single network. The NAS performs multiple lines will be aggregated onto a single network.
functions in the network.
The NAS is the aggregation point for the subscriber traffic. It The NAS performs multiple functions in the network. The NAS is the
provides aggregation capabilities (e.g. IP, PPP, ATM) between the aggregation point for subscriber traffic. It provides aggregation
Regional/Access Network and the NSP or ASP. These include capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network
traditional ATM-based offerings and newer, more native IP-based and the NSP or ASP. These include traditional ATM-based offerings
services. This includes support for Point-to-Point Protocol over ATM and newer, more native IP-based services. This includes support for
(PPPoA) and PPP over Ethernet (PPPoE), as well as direct IP services Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
encapsulated over an appropriate layer 2 transport. (PPPoE), as well as direct IP services encapsulated over an
appropriate layer 2 transport.
Beyond aggregation, NAS is also the injection point for policy Beyond aggregation, the NAS is also the injection point for policy
management and IP QoS in the Regional/Access Networks. In order to management and IP QoS in the Regional/Access Networks. To allow IP
allow IP QoS support over an existing non-IP-aware layer 2 access QoS support over an existing non-IP-aware layer 2 access network
network without using multiple layer 2 QoS classes, a mechanism based without using multiple layer 2 QoS classes, a mechanism based on
on hierarchical scheduling is used. This mechanism defined in hierarchical scheduling is used. This mechanism, defined in
[TR-059], preserves IP QoS over the ATM network between the NAS and [TR_059], preserves IP QoS over the ATM network between the NAS and
the RGs by carefully controlling downstream traffic in the NAS, so the routing gateway (RG) at the edge of the subscriber network, by
that significant queuing and congestion does not occur further down carefully controlling downstream traffic in the NAS, so that
the ATM network. This is achieved by using a diffserv-aware significant queuing and congestion does not occur further down the
hierarchical scheduler in the NAS that will account for downstream ATM network. This is achieved by using a diffserv-aware hierarchical
trunk bandwidths and DSL synch rates. scheduler in the NAS that will account for downstream trunk
bandwidths and DSL synch rates.
[ANCP-FRAMEWORK] provides detailed definition and functions of each [RFC5851] provides detailed definition and functions of each network
network element in the broadband reference architecture. element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation --> <------- Premises -------> <--- Aggregation --> <------- Premises ------->
Network Network Network Network
+------------------+ +--------------------------+ +------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ |-|+-----+ +---+ +---------+ | +---------+ +---+ | +-----+ +------+ |-|+-----+ +---+ +---------+ |
NSP| | +-|NAS|-| |ATM |-|Access| | ||DSL |-|HGW|-|Subscriber|| NSP| | +-|NAS|-| |ATM |-|Access| | ||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices || ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+| |Broadband| | +---+ | +------+ | |+-----+ +----------+|
skipping to change at page 7, line 45 skipping to change at page 9, line 45
in IEEE 802.ad. Stacked VLAN tags provide one possible way to create in IEEE 802.ad. Stacked VLAN tags provide one possible way to create
equivalent of "virtual paths" and "virtual circuits" in the equivalent of "virtual paths" and "virtual circuits" in the
aggregation network. The "outer" vlan could be used to create a form aggregation network. The "outer" vlan could be used to create a form
of "virtual path" between a given DSLAM and a given NAS. And "inner" of "virtual path" between a given DSLAM and a given NAS. And "inner"
VLAN tags to create a form of "virtual circuit" on a per DSL line VLAN tags to create a form of "virtual circuit" on a per DSL line
basis. This is 1:1 VLAN allocation model. An alternative model is basis. This is 1:1 VLAN allocation model. An alternative model is
to bridge sessions from multiple subscribers behind a DSLAM into a to bridge sessions from multiple subscribers behind a DSLAM into a
single VLAN in the aggregation network. This is N:1 VLAN allocation single VLAN in the aggregation network. This is N:1 VLAN allocation
model. Architectural and topological models of an Ethernet model. Architectural and topological models of an Ethernet
aggregation network in context of DSL aggregation are defined in aggregation network in context of DSL aggregation are defined in
[TR-101] [TR_101]
4. Access Node Control Protocol 4. Access Node Control Protocol -- General Aspects
4.1. Overview
A dedicated control protocol between NAS and access nodes can This section specifies aspects of the Access Node Control Protocol
facilitate "NAS managed" tight QOS control in the access network, (ANCP) that are generally applicable. As indicated above, ANCP is
simplified OSS infrastructure for service management, optimized derived from GSMPv3 [RFC3292]. Reference to [RFC3292] is made where
multicast replication to enable video services over DSL, subscriber this is applicable, but ANCP introduces numerous modifications and
statistics retrieval on the NAS for accounting purposes, and fault extensions to the basic GSMPv3 protocol. Moreover, ANCP uses only a
isolation capability on the NAS for the underlying access technology. subset of the messages, message contents, and procedures defined for
This dedicated control plane is referred to as "Access Node Control GSMPv3.
Protocol" (ANCP). This document specifies relevant extensions to
GSMPv3 as defined [RFC3292] to realize ANCP.
Following sections discuss the use of ANCP for implementing: The following are the only GSMPv3 [RFC3292] messages that are
currently used by ANCP.
o Dynamic discovery of access topology by the NAS to provide tight Event Messages
QOS control in the access network.
o Pushing to the access-nodes, subscriber and service data retrieved * Port UP Message
by the NAS from an OSS system (e.g. radius server), to simplify
OSS infrastructure for service management.
o Optimized, "NAS controlled and managed" multicast replication by * Port DOWN Message
access-nodes at L2 layer.
o NAS controlled, on-demand access-line test capability (rudimentary These messages are used by the ANCP topology discovery capability.
end-to-end OAM).
In addition to DSL, alternate broadband access technologies (e.g. Port Management Messages These messages are used by the ANCP "line
Metro-Ethernet, Passive Optical Networking, WiMax) will have similar configuration" and ANCP "line testing" capabilities.
challenges to address, and could benefit from the same approach of a
control plane between a NAS and an Access Node (e.g. OLT), providing
a unified control and management architecture for multiple access
technologies, hence facilitating migration from one to the other
and/or parallel deployments.
GSMPv3 is an ideal fit for implementing ANCP. It is extensible and Adjacency Protocol Messages These messages are used to bring up a
can be run over TCP/IP, which makes it possible to run over different protocol adjacency between a NAS and an AN.
access technologies.
4.2. ANCP based Access Topology Discovery ANCP modifies and extends some basic GSMPv3 procedures. These
modifications and extensions are summarized below, and described in
more detail in the succeeding sections.
4.2.1. Goals o ANCP provides support for a capability negotiation mechanism
between ANCP peers by extending the GSMPv3 adjacency protocol.
This mechanism and corresponding adjacency message extensions are
defined in section Section 4.3.
[TR-059] discusses various queuing/scheduling mechanisms to avoid o The TCP connection establishment procedure in ANCP deviates
congestion in the access network while dealing with multiple flows slightly from connection establishment in GSMPv3 as specified in
with distinct QoS requirements. Such mechanisms require that the NAS [RFC3293]. This is described in section Section 4.2.
gains knowledge about the topology of the access network, the various
links being used and their respective net data rates. Some of the
information required is somewhat dynamic in nature (e.g. DSL sync
rate, and therefore also the net data rate), hence cannot come from a
provisioning and/or inventory management OSS system. Some of the
information varies less frequently (e.g. capacity of a DSLAM uplink),
but nevertheless needs to be kept strictly in sync between the actual
capacity of the uplink and the image the NAS has of it.
Following section describes ANCP messages that allow the Access Node o ANCP adds content to GSMPv3 messages in the form of additional
(e.g. DSLAM) to communicate to the NAS, access network topology fixed fields and Type-Length-Value (TLV) structures. TLVs also
information and any corresponding updates. provide flexibility to both GSMPv3 and ANCP-specific messages
because their order and whether or not specific TLVs are present
can vary from one message instance to the next.
Some of the parameters that can be communicated from the DSLAM to the 4.1. Protocol Version
NAS include DSL line state, actual upstream and downstream net data
rates of a synchronized DSL link, maximum attainable upstream and
downstream net data rates, interleaving delay etc. Topology
discovery is specifically important in case the net data rate of the
DSL line changes over time. The DSL net data rate may be different
every time the DSL modem is turned on. Additionally, during the time
the DSL modem is active, data rate changes can occur due to
environmental conditions (the DSL line can get "out of sync" and can
retrain to a lower value).
4.2.2. Message Flow GSMPv3 messages contain an 8-bit protocol version field. As
described below, ANCP subdivides this into two 4-bit sub-fields, for
version and sub-version. Implementations of this version of the ANCP
specification MUST set the version sub-field to 3 and the sub-version
sub-field to 1. That is, the hexadecimal representation of the value
of the complete protocol version field MUST be 0x31.
When a DSL line initially comes up or resynchronizes to a different RFC EDITOR'S NOTE: please change the value of sub-version in the
rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message above paragraph to 2 (respectively a version field value of 0x32) in
to the NAS. The extension field in the message carries the TLVs the published specification. For an explanation see the Introduction
containing DSL line specific parameters. On a loss of signal on the above.
DSL line, a GSMP PORT DOWN message is generated by the DSLAM to the
NAS. In order to provide expected service level, NAS needs to learn
the initial attributes of the DSL line before the subscriber can log
in and access the provisioned services for the subscriber. Figure 2
summarizes the interaction.
<----- Port UP(EVENT Message) <----- DSL 4.2. ANCP Transport
(default line parameters) Signal
1. NAS ------------------ Access ----------- Home ----- Subscriber This document specifies the use of TCP/IP for transport of ANCP
Node Gateway messages. Other specifications may introduce additional transports
in the future.
<----- Port UP (EVENT Message) <----- DSL In the case of ATM access, a separate PVC (control channel)
(updated line parameters) Resynch capable of transporting IP may be configured between NAS and the
2. NAS ------------------ Access ----------- Home ------ Subscriber AN for ANCP messages.
Node Gateway
<--- Port DOWN (EVENT Message) <---- DSL In the case of an Ethernet access/aggregation network, a typical
Loss of Signal practice is to send the Access Node Control Protocol messages over
a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
identifier (VLAN ID).
3. NAS ----------------- Access ------------- Home ----- Subscriber When transported over TCP, ANCP messages MUST use the encapsulation
Node Gateway specified for GSMPv3 messages carried over TCP in [RFC3293]. This
encapsulation consists of a four-byte header field prepended to the
ANCP message as shown in Figure 2.
Figure 2: Message flow (ANCP mapping) for topology discovery 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (0x880C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ANCP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Event message with PORT UP message type (80) is used for Figure 2: Encapsulation of ANCP Messages Over TCP/IP
conveying DSL line attributes to the NAS. This message with relevant
extensions is defined in section Section 5.4.2.
4.3. ANCP based Line Configuration The fields of the encapsulating header are as follows:
4.3.1. Goals Identifier: This 2-byte field identifies a GSMP or ANCP message.
The type code for GSMP and ANCP messages is 0x880C (i.e., the same
as GSMP's Ethertype).
Following dynamic discovery of access topology (identification of DSL Length: This 2-byte unsigned integer indicates the total length of
line and its attributes) as assisted by the mechanism described in the ANCP message only. It does not include the 4-byte
the previous section (topology discovery), the NAS could then query a encapsulating header.
subscriber management OSS system (e.g. RADIUS server) to retrieve
subscriber authorization data (service profiles, aka user
entitlement). Most of such service mechanisms are typically enforced
by the NAS itself, but there are a few cases where it might be useful
to push such service parameter to the DSLAM for local enforcement of
a mechanism (e.g. DSL-related) on the corresponding subscriber line.
One such example of a service parameter that can be pushed to the
DSLAM for local enforcement is DSL "interleaving delay". Longer
interleaving delay (and hence stringent error correction) is required
for a video service to ensure better video "quality of experience",
whereas for a VoIP service or for "shoot first" gaming service, a
very short interleaving delay is more appropriate. Another relevant
application is downloading per subscriber multicast channel
entitlement information in IPTV applications where the DSLAM is
performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS
could achieve the goal of pushing line configuration to the DSLAM by
an interoperable and standardized protocol.
If a subscriber wants to choose a different service, it can require The Access Node MUST initiate the TCP session to the NAS. This is
an OPEX intensive reconfiguration of the line via a network operator, necessary to avoid static provisioning on the NAS for all the ANs
possibly implying a business-to-business transaction between an ISP that are being served by the NAS. It is easier to configure a given
and an access provider. Using ANCP for line configuration from the AN with the single IP address of the NAS that serves the AN. This is
NAS dramatically simplifies the OSS infrastructure for service a deviation from [RFC3293], which indicates that the controller
management, allowing fully centralized subscriber-related service initiates the TCP connection to the switch.
data (e.g. RADIUS server back-end) and avoiding complex cross-
organization B2B interactions.
The best way to change line parameters would be by using profiles. The NAS MUST listen for incoming connections from the Access Nodes.
These profiles (DSL profiles for different services) are pre- Port 6068 is used for TCP connection.
configured on the DSLAMs. The NAS can then indicate a reference to
the right DSL profile via ANCP. Alternatively, discrete DSL
parameters can also be conveyed by the NAS in ANCP.
4.3.2. Message Flow In the event of an ANCP transport protocol failure, all pending ANCP
messages destined to the disconnected recipient SHOULD be discarded
until the transport is re-established.
Triggered by topology information reporting a new DSL line or 4.3. Use of the GSMPv3 Adjacency Protocol
triggered by a subsequent user session establishment (PPP or DHCP),
the NAS may send line configuration information (e.g. reference to a
DSL profile) to the DSLAM using GSMP Port Management messages. The
NAS may get such line configuration data from a policy server (e.g.
RADIUS). Figure 3 summarizes the interaction.
1.DSL Signal Section 11 of [RFC3292] defines the GSMPv3 adjacency protocol. ANCP
<----------- reuses the GSMPv3 adjacency protocol to synchronize the NAS and
2. Port UP (EVENT Message) Access Nodes and maintain the ANCP session. After the TCP connection
(Access Topology Discovery) is established, adjacency protocol messages MUST be exchanged as
<---------------- specified in Section 11 of [RFC3292], subject to the additional
3. PPP/DHCP Session specifications of this section. ANCP messages other than adjacency
<-------------------------------- protocol messages MUST NOT be sent until the adjacency protocol has
4. Authorization achieved synchronization.
& Authentication
<-------------------
Port Management Message
(Line Configuration)
5. -------->
+----------+ +-----+ +-----+ +-------+ +-----------+
|Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber |
|Policy | +-----+ +-----+ |Gateway| +-----------+
|Server | +-------+
+----------+
Figure 3: Message flow - ANCP mapping for Initial Line Configuration 4.3.1. ANCP Adjacency Message Format
The NAS may update the line configuration due to a subscriber service The GSMPv3 adjacency message format defined in Section 11 of
change (e.g. triggered by the policy server). Figure 4 summarizes [RFC3292] is modified and extended for ANCP as shown in Figure 3
the interaction. below. The 8-bit "version" field in the GSMPv3 adjacency protocol
messages is modified to carry the ANCP version (four bits) and sub-
version (four bits). See Section 4.1 for the values to set for
version and sub-version for the present version of this
specification. In addition to the modification of the version field,
ANCP adds several new fields. These are described below the figure.
1. PPP/DHCP Session 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Sub | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | PFlag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tech Type | # of Caps | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+ 2. Service On Demand Figure 3
| |<-----------------------------------------------
| Web portal|
| OSS etc | 3.Change of 4.Port Management
| | Authorization Message
|Radius AAA | --------> (Updated Line
| Policy | Config - New Profile)
| | ------------->
| | +------+ +-------+ +---------+ +----------+
| |----| NAS |-----| AN |---| Home |--|Subscriber|
| | +------+ +-------+ | Gateway | +----------+
+-----------+ +---------+
Figure 4: Message flow - ANCP mapping for Updated Line Configuration [Editor's Note: it seems likely this text and Section 4.3 will have
to be modified to provide for multiple capability sets (for different
Tech Type values).]
The format of relevant extensions to port management message is The fields added by ANCP are as follows:
defined in section Section 5.4.3. The line configuration models
could be viewed as a form of delegation of authorization from the NAS
to the DSLAM.
4.4. ANCP based OAM Tech Type: indicates the technology to which the capability
extension applies. An IANA registry is maintained for possible
values of the Tech Type field. This specification assigns the
Tech Type value 0x05 to DSL.
In a mixed Ethernet and ATM access network (including the local # of Caps: indicates the number of capability fields that follow.
loop), it is desirable to provide similar mechanisms for connectivity
checks and fault isolation, as those used in an ATM based
architecture. This can be achieved using an ANCP based mechanism
until end-to-end Ethernet OAM mechanisms are more widely implemented
in various network elements.
A simple solution based on ANCP can provide NAS with an access-line Total Length: indicates the total number of bytes occupied by the
test capability and to some extent fault isolation. Controlled by a capability fields that follow.
local management interface the NAS can use an ANCP operation to
trigger the access-node to perform a loopback test on the local-loop
(between the access-node and the CPE). The access-node can respond
via another ANCP operation the result of the triggered loopback test.
In case of ATM based local-loop the ANCP operation can trigger the
access-node to generate ATM (F4/F5) loopback cells on the local loop.
In case of Ethernet, the access-node can trigger an Ethernet loopback
message(per EFM OAM) on the local-loop.
4.4.1. Message Flow Capability Fields: Each capability field indicates one ANCP
capability supported by the sender of the adjacency message.
Negotiation of a common set of capabilities to be supported within
the ANCP session is described in Section 4.3.2. The detailed
format of a capability field is described below.
"Port Management" message can be used by the NAS to request access The format of a capability field is shown in Figure 4:
node to trigger a "remote loopback" test on the local loop. The
result of the loopback test can be asynchronously conveyed by the
access node to the NAS in a "Port Management" response message. The
format of relevant extensions to port management message is defined
in section The format of relevant extensions to port management
message is defined in section Section 5.4.4. Figure 5 summarizes the
interaction.
Port Management Message 0 1 2 3
(Remote Loopback ATM loopback 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
Trigger Request) OR EFM Loopback +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. ----------------> 2. ---------> | Capability Type | Capability Length |
<--------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------+ +-----+ +-------+ +----------------+ | |
|Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE | ~ ~
|Policy Server| +-----+ +-------+ | (DSL Modem + | ~ Capability Data ~
+-------------+ |Routing Gateway)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+----------------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
Figure 5: Message Flow: ANCP based OAM Figure 4: Capability Field
5. Access Node Control Protocol (ANCP) The sub-fields of this structure are as follows:
ANCP uses a subset of GSMPv3 messages described in [RFC3292] to Capability Type: indicates the specific capability supported. An
implement currently defined use-cases. GSMPv3 general message IANA registry exists for values of this sub-field. The values
format, used by all GSMP messages other than adjacency protocol specified by this document are listed below.
messages, is defined in section 3.1.1 of GSMPv3 [RFC3292]. ANCP
modifies this base GSMPv3 message format. The modified GSMPv3 Capability Length: the number of bytes of data contained in the
message format is defined as follows: Capability Data sub-field, excluding padding. If the definition
of a particular capability includes no capability data, the value
of the Capability Length sub-field is zero.
Capability Data: contains data associated with the capability as
specified for that capability. If the definition of a particular
capability includes no capability data, the Capability Data sub-
field is absent (has zero length). Otherwise, the Capability Data
sub-field MUST be padded with zeroes as required to terminate on a
4-byte word boundary. The possibility of specifying capability
data provides the flexibility to advertise more than the mere
presence or absence of a capability if needed.
The following capabilities are defined for ANCP as applied to DSL
access:
1. Capability Type : DSL Topology Discovery = 0x01
Length (in bytes) : 0
Capability Data : NULL
For the detailed protocol specification of this capability see
Section 5.2.
2. Capability Type : DSL Line Configuration = 0x02
Length (in bytes) : 0
Capability Data : NULL
For the detailed protocol specification of this capability see
Section 5.3.
3. Capability Type : DSL Line Testing = 0x04
Length (in bytes) : 0
Capability Data : NULL
For the detailed protocol specification of this capability see
Section 5.4.
4.3.2. ANCP Adjacency Procedures
The NAS MUST set the M-flag in the SYN message (signifying it is the
master). Once the adjacency is established, periodic adjacency
messages (type ACK) MUST be exchanged. The default for the ACK
interval to be advertised in the adjacency messages is 10 sec for
ANCP. The actual value SHOULD be configurable and is an
implementation choice. It is RECOMMENDED that both ends specify the
same timer value; to achieve this, each end SHOULD compare the timer
value in the first adjacency message it receives with its own
preferred value and agree to use the higher of the two values. That
is, the node that receives a higher timer value than its own SHOULD
reply in its subsequent adjacency messages (such as SYNACK, ACK) with
the higher timer value.
In the adjacency protocol the version and the sub-version fields are
used for version negotiation. The version negotiation is performed
before synchronisation is achieved. In a SYN message the version/
sub-version fields always contain the highest version understood by
the sender. A receiver receiving a SYN message with a version/
sub-version higher than it understands MUST silently discard that
message. A receiver receiving a SYN message with a version/
sub-version within the range of versions that it understands MUST
reply with a SYNACK with the version/sub- version from the received
SYN in its ANCP version/sub-version fields. This defines the
version/sub-version of the ANCP protocol to be used while the
adjacency remains synchronised. All other ANCP messages within the
session MUST use the agreed version in the version/sub-version
fields.
The semantics and suggested values for Code, "Sender Name", "Receiver
Name", "Sender Instance", and "Receiver Instance" fields are as
defined in Section 11 of [RFC3292]. The "Sender Port", and "Receiver
Port" SHOULD be set to 0 by both ends. The pType field SHOULD be set
to 0 (No Partition). The pFlag SHOULD be set to 1 (New Adjacency).
If the adjacency times out on either end, due to not receiving an
adjacency message for a duration of (3 * Timer value), where the
timer value is specified in the adjacency message, all the state
received from the ANCP neighbor SHOULD be cleaned up, and the TCP
connection SHOULD be 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.
The handling defined above will need some modifications when ANCP
graceful restart procedures are defined. These procedures will be
defined in a separate draft.
Both the NAS and the Access Node MUST advertise supported
capabilities in the adjacency messages they send. If a received
adjacency message indicates no support for a capability that is
supported by the receiving device, it MUST turn off the capability
locally and MUST send an updated adjacency message with the
corresponding capability field omitted to match the received
capability set. This process will eventually result in both sides
agreeing on the minimal set of supported capabilities. The adjacency
MUST NOT come up unless the capabilities advertised by the controller
and the controlled device match.
After initial synchronization, if at any time a capability mismatch
is detected, the adjacency MUST be brought down (RSTACK MUST be
generated by the device detecting the mismatch), and synchronization
MUST be re-attempted.
4.4. ANCP General Message Formats
This section describes the general format of ANCP messages other than
the adjacency messages.
The 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 as
shown in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Modified GSMPv3 message format Figure 5: ANCP General Message Format
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. [RFC
Editor's note: sub-version needs to be changed from 1 to 2 upon
publication]
Result:
The Result field derived from GSMP [RFC3292] has the following
codes:
Ignore:
Res = 0x00 - Ignore this field on receipt and follow the
procedures specified for the received message type.
Nack: 4.4.1. The ANCP Message Header
Res = 0x01 - Result code indicating that no response is The immediately visible differences from GSMPv3 are the subdivision
expected to the message other than in cases of failure of the Version field into version and sub-version, and the
caused during the processing of the message contents or that reallocation of space between Result and Code to enlarge the range
of the contained directive(s). for Code. 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 ANCP protocol. The Result field in the message header
has been modified to be 4 bits long, and the Code field to be 12 bits
long.
AckAll: A complete explanation of the header fields is as follows:
Res = 0x02 - Result code indicating that a response to the Version and Sub-version: The version of the ANCP protocol that was
message is requested in all cases. It is specifically agreed for the session during adjacency negotiation. For the
intended to be used in some cases for Request messages only, values that must be placed into these fields, see Section 4.1.
and is not to be used in Event messages.
Success: Message Type: The ANCP message type. Message type values are
registered in a common GSMPv3/ANCP IANA registry.
Res = 0x03 - Set by receiver to indicate successful Result: The Result field derived from GSMPv3 [RFC3292]. Ignore
execution of all directives in the corresponding Request (0x0) is a new value added by ANCP. The remaining Result values
message. below are a subset of those defined for GSMPv3. GSMPv3 expected
the sender of a request to choose between NAck (0x1) and AckAll
(0x2) according to its needs. ANCP specifies what Result value
each request should have. Responses indicate either Success (0x3)
or Failure (0x4) as the case may be.
Failure: Ignore: Res = 0x0 - Ignore this field on receipt and follow the
procedures specified for the received message type.
Res = 0x4 - Set by receiver in the Response message if one Nack: Res = 0x1 - Result code indicating that no response is
or more directives in the corresponding Request message expected to the message other than in cases of failure caused
fails. during the processing of the message contents or of the
contained directive(s).
Message-Type: AckAll: Res = 0x2 - Result code indicating that a response to the
message is requested in all cases.
The GSMP and ANCP message type. Success: Res = 0x3 - Set in a response message by the receiver of
a request to indicate successful execution of all directives in
the corresponding request message.
Code: Failure: Res = 0x4 - Set in a response message by the receiver of
a request to indicate either that there was an error in the
content of the request message or that one or more directives
in the corresponding request could not be executed
successfully.
This field gives further information concerning the result in a Code: This field gives further information concerning the result in
response message. It is mostly used to pass an error code in a 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 failure response but can also be used to give further information
in a success response message or an event message. In a request in a success response message or an event message. In a request
message, the code field is not used and is set to zero. In an message, the Code field is not used and MUST be set to zero.
adjacency protocol message, the Code field is used to determine
the function of the message.
ANCP implementations MAY use any of the Code values specified in ANCP implementations MAY use any of the Code values specified in
the IANA registry "Global Switch Management Protocol version 3 the IANA registry "Global Switch Management Protocol version 3
(GSMPv3) Failure Response Message Name Space" if they appear (GSMPv3) Failure Response Message Name Space" if they appear
applicable. In particular, the values: applicable. In particular, the values:
2 Invalid request message (i.e., a properly formed message which 2 Invalid request message (i.e., a properly formed message which
violates the protocol through its timing or direction of violates the protocol through its timing or direction of
transmission) transmission)
4 One or more of the specified ports do not exist 4 One or more of the specified ports do not exist
6 One or more of the specified ports are down 6 One or more of the specified ports are down
7 Invalid Partition ID 7 Invalid Partition ID
19 Out of resources (e.g. memory exhausted, etc.) 19 Out of resources (e.g. memory exhausted, etc.)
30 The limit on the maximum number of point-to- multipoint 30 The limit on the maximum number of point-to-multipoint
connections that the switch can support has been reached connections that the switch can support has been reached
31 The limit on the maximum number of branches that the specified 31 The limit on the maximum number of branches that the specified
point-to-multipoint connection can support has been reached point-to-multipoint connection can support has been reached
may unfortunately apply to ANCP usage, including the case where may unfortunately apply to ANCP usage, where "Port" is interpreted
"Port" is interpreted to mean Target as defined in section to mean an access line or a Target as defined in Section 6.2.1.
Section 5.4.5.1.1
Instead of the value:
3 The specified request is not implemented on this switch Instead of the value:
specified by [RFC3292], this specification defines a new value: 3 The specified request is not implemented on this switch
81 Request message type not implemented specified by [RFC3292], this specification defines a new value:
This value MAY be sent in a failure response from either the AN or 81 Request message type not implemented
the NAS. This specification also defines the additional values:
82 Transaction identifier out of sequence This value MAY be sent in a failure response from either the AN or
the NAS. This specification also defines the additional values:
83 Malformed message 82 Transaction identifier out of sequence
84 TLV or value not supported by negotiated capability set 83 Malformed message
ANCP extensions defining new code values SHOULD use the range 0x0100 84 TLV or value not supported by negotiated capability set
through 0x01ff for this purpose.
The range of values from 256 to 4095 is reserved for IETF use. ANCP extensions defining new code values SHOULD use the range 256
(0x100) through 511 (0x1FF) for this purpose.
Partition ID: The range of values from 256 to 4095 is reserved for IETF use.
This field is a 8 bit number which signifies a partition on the Partition ID: This field is a 8 bit number which signifies a
AN. partition on the AN.
AN and NAS MAY agree on the partition ID using one of the The AN and NAS MAY agree on the partition ID using one of the
following possible options: following possible options:
1 - The partition ID could be configured on the AN and learnt by 1 - The partition ID could be configured on the AN and learned by
NAS in the adjacency message; the NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as 2 - The partition ID could be statically configured on the NAS as
part of configuring the neighbor information. part of configuring the neighbor information.
Transaction ID: Transaction ID: 24-bit field set by the sender of a request message
to associate a response message with the original request message.
Unless otherwise specified for a given message type, the
Transaction ID in request messages MUST be set to a value in the
range (1, 2^24 - 1). When used in this manner, the Transaction ID
sequencing MUST be maintained independently for each ANCP
adjacency and per message type. Furthermore, it SHOULD be
incremented linearly for each new message of the given type,
cycling back to 1 after running the full range. Each Transaction
ID sequence SHOULD be reinitialized to a random non-zero value
when an adjacency is negotiated. For event messages, the
Transaction ID SHOULD be set to zero.
24-bit field set by the sender of a Request message to associate a Unless otherwise specified, the default behaviour for all ANCP
Response message with the original Request message. The receiver responses is that the value of the Transaction ID MUST be copied
of a Request message reflects the transaction ID from the Request from the corresponding request message.
message in the corresponding Response message. For event
messages, the transaction identifier SHOULD be set to zero. The
Transaction Identifier is not used, and the field is not present,
in the adjacency protocol.
I flag: I flag and SubMessage Number: An ANCP implementation SHOULD set the
I Flag and subMessage Number fields to 1 to signify no
fragmentation.
An ANCP implementation SHOULD set "I" and subMessage fields to 1 Length: Length of the ANCP message including its header fields and
to signify no fragmentation. defined ANCP message body.
Length: 4.4.2. The ANCP Message Body
Length of the GSMP message including its header fields and defined The detailed contents of the message payload portion of a given ANCP
GSMP message body. message may vary with the capability in the context of which it is
being used. However, the general format consists of zero or more
fixed fields, followed by a variable amount of data in the form of
Type-Length-Value (TLV) data structures.
Additional General Message Information: The general format of a TLV is shown in Figure 6:
o Any field in a GSMP message that is unused or defined as 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
"reserved" MUST be set to zero by the sender and ignored by the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
receiver; | Type (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Flags that are undefined will be designated as: x: reserved. Figure 6: General TLV Format
Following are the relevant GSMPv3 messages defined in [RFC3292], that The fields of a TLV are defined as follows:
are currently used by ANCP. Other than the message types explicitly
listed below, no other GSMPv3 messages are used by ANCP currently.
o Event Messages Type: The TLV Type is a 16-bit unsigned value identifying the TLV
type and nature of its contents. An IANA registry has been
established for ANCP TLV Type codes.
* Port UP Message Length The number of bytes of data in the Value field of the TLV,
excluding any padding required to bring this TLV to a 4-byte word
boundary (see "Value" below). If a TLV contains other TLVs, any
padding in the contained TLVs MUST be included in the value of
Length.
* Port DOWN Message If the TLV contains another TLV followed by other data, the
outer TLV will not be properly parsable unless Length is set as
indicated; if the interior padding is omitted from Length, as
many bytes of data at the end of the outer TLV will be missed.
If the outer TLV contains another TLV as its final field it
requires no padding of its own (since the contained TLV
including padding ends on a 4-byte boundary). In this case the
issue is one of consistency rather than parsability, since the
padding of that final TLV could be omitted from Length without
loss of data.
These messages are used by ANCP topology discovery use-case. Depending on the specification of the TLV, the value of Length may
be zero, a constant for all instances of the TLV, or a varying
quantity.
o Port Management Messages Value The actual data carried by the TLV, if any. The value field
in each TLV MUST be padded with zeroes as required to align with a
4-byte word boundary. The Value field of a TLV may include fixed
fields and/or other TLVs.
* These messages are used by ANCP "line configuration" use-case Unless otherwise specified, TLVs MAY be added to a message in any
and ANCP OAM use-case. order. If the recipient of a message does not understand a
particular TLV, it MUST silently ignore it.
o Adjacency Protocol Messages A number of TLVs are specified in the remainder of this document.
* These messages are used to bring up a protocol adjacency 4.4.2.1. Additional Conventions and General Requirements
between a NAS and an AN.
ANCP modifies and extends few basic GSMPv3 procedures. These Any field in a message that is inherited from GSMPv3 and is unused in
modifications and extensions are summarized below, and described in ANCP and any field that is explicitly shown as Reserved MUST be set
more detail in the succeeding sections. to all zeroes by the sender and MUST be ignored by the receiver.
o ANCP provides support for a capability negotiation mechanism Such fields could be assigned a specific purpose in a future
between ANCP peers by extending the GSMPv3 adjacency protocol. version of this specification.
This mechanism and corresponding adjacency message extensions are
defined in section Section 5.3
o TCP connection establishment procedure in ANCP deviates slightly Unused bits in a flag field are shown in figures as 'x'. The above
from the connection establishment in GSMPv3 as specified in requirement (sender set to zero, receiver ignore) applies to such
[RFC3293]. This is described in section Section 5.1 unused bits.
o ANCP makes GSMPv3 messages extensible and flexible by adding a 5. ANCP Capabilities For Digital Subscriber Lines (DSL)
general "extension block" to the end of the relevant GSMPv3
messages. The "extension block" contains a TLV structure to carry
information relevant to each ANCP use-case. The format of the
"extension block" is defined in section Section 5.4.1.1.
o 5.1. Overview
5.1. ANCP/TCP connection establishment DSL is a widely deployed access technology for Broadband Access for
Next Generation Networks. Specifications such as [TR_059], [TR_058],
and [TR_092] describe possible architectures for these access
networks. The scope of these specifications includes the delivery of
voice, video, and data services.
ANCP will use TCP for exchanging protocol messages [RFC3293]. defines When deploying value-added services across DSL access networks,
the GSMP message encapsulation for TCP. The TCP session is initiated special attention is required to assure quality of service and
from the DSLAM (access node) to the NAS (controller). This is service control, which implies a tighter coordination between network
necessary to avoid static provisioning on the NAS for all the DSLAMs elements in the broadband access network without burdening the OSS
that are being served by the NAS. It is easier to configure a given layer.
DSLAM with the single IP address of the NAS that serves the DSLAM.
This is a deviation from [RFC3293] which indicates that the
controller initiates the TCP connection to the switch.
When GSMP messages are sent over a TCP connection a four-byte TLV This document specifies basic ANCP capabilities for use specifically
header field is prepended to the GSMP message to provide delineation in controlling Access Nodes serving DSL access (Tech Type = 0x05).
of GSMP messages within the TCP stream. The same ANs could be serving other access technologies (e.g. Metro-
Ethernet, Passive Optical Networking, WiMax), in which case the AN
will also have to support the corresponding other-technology-specific
capabilities. These additional capabilities are not specified here,
but may be specified in other documents.
0 1 2 3 The DSL capabilities specified in this section are:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GSMPv3 with TCP/IP Encapsulation message format DSL Topology Discovery: Dynamic discovery of access topology and DSL
line attributes by the NAS, to support tight QOS control in the
access network.
Type DSL Line Configuration: Pushing subscriber and service data
retrieved by the NAS from an OSS system (e.g. RADIUS server) to
the Access Nodes, to simplify OSS infrastructure for service
management.
This 2-byte field indicates the type code of the following DSL Line Testing: NAS controlled, on-demand access- line test
message. The type code for GSMP messages is 0x88-0C (i.e., the capability (rudimentary end-to-end OAM).
same as GSMP's Ethertype).
Length 5.1.1. ATM-Specific Considerations
This 2-byte unsigned integer indicates the total length of the
GSMP message only. It does not include the 4-byte TLV header.
NAS listens for incoming connections from the access nodes. Port Topology discovery and line configuration involve the DSL line
6068 is used for TCP connection. Adjacency protocol messages, which attributes. For ATM based access networks, the DSL line on the DSLAM
are used to synchronize the NAS and access-nodes and maintain is identified by the port and PVP/PVC corresponding to the
handshakes, are sent after the TCP connection is established. ANCP subscriber. The DSLAMs are connected to the NAS via an ATM access
messages other than adjacency protocol messages may be sent only aggregation network. Since, the DSLAM (Access Node) is not directly
after the adjacency protocol has achieved synchronization. connected to the NAS, the NAS needs a mechanism to learn the DSL line
identifier (more generally referred to as "access loop circuit ID")
corresponding to a subscriber. The access loop circuit ID has no
local significance on the NAS. The ANCP messages for topology
discovery and line configuration carry opaque Access-Loop-Circuit-ID
values which have only local significance on the DSLAMs.
In the case of ATM access, a separate PVC (control channel) capable The access loop circuit identifier can be carried as an ASCII string
of transporting IP would be configured between NAS and the DSLAM for in the ANCP messages. This allows ANCP to be decoupled from the
ANCP messages. specifics of the underlying access technology being controlled. On
the other hand, this requires a NAS mechanism by which each such
identifier can be correlated to the context of an aggregation-
network-facing IP interface (corresponding to the subscriber) on the
NAS. This will typically require local configuration of such IP
interfaces, or of the underlying ATM interfaces.
In case of an Ethernet access/aggregation network, a typical practice 5.1.2. Ethernet-Specific Considerations
is to send the Access Node Control Protocol messages over a dedicated
Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN
ID).
5.2. ANCP Connection keepalive One possible way of approaching the use of Ethernet technology in the
access aggregation network is to recreate the equivalent of Virtual
Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN
tags. As an example, one can use an "outer" VLAN to create a form of
"virtual path" between a given DSLAM and a given NAS, and then use
"inner" VLAN tags to create a form of "virtual circuit" on a per DSL
line basis. In this case, VLAN tags conveyed in topology discovery
and line configuration messages will allow unique identification of
the DSL line in a straightforward manner, assuming the VLAN tags are
not translated in some way by the aggregation network, and are unique
across physical ports.
GSMPv3 defines an adjacency protocol. The adjacency protocol is used However, some carriers do not wish to use this "connection oriented"
to synchronize states across the link, to negotiate which version of approach. Therefore, an alternative model is to bridge sessions from
the GSMP protocol to use, to discover the identity of the entity at multiple subscribers behind a DSLAM to a single VLAN in the
the other end of a link, and to detect when it changes. GSMP is a aggregation network. This is the N:1 model. In this model, or in
hard state protocol. It is therefore important to detect loss of the case where user traffic is sent untagged, the Access Node needs
contact between switch and controller, and to detect any change of to insert the exact identity of the DSL line in the topology
identity of switch or controller. No protocol messages other than discovery and line configuration messages, and then have a mechanism
those of the adjacency protocol may be sent across the link until the by which this can be correlated to the context of an aggregation-
adjacency protocol has achieved synchronization. There are no network-facing IP interface (for the subscriber) on the NAS. This
changes to the base GSMP adjacency protocol for implementing ANCP. can either be based on local configuration on the NAS, or on the fact
that such DSLAM (Access Node) typically inserts the access loop
circuit ID in subscriber signaling messages relayed to the NAS (i.e.
DHCP or PPPoE discovery messages).
The NAS will set the M-flag in the SYN message (signifying it is the Section 5.2.3.3 defines TLVs to represent the "access loop circuit
master). Once the adjacency is established, periodic adjacency ID".
messages (type ACK) are exchanged. The default ACK interval as
advertised in the adjacency messages is 10 sec for ANCP. It SHOULD
be configurable and is an implementation choice. It is recommended
that both ends specify the same timer value, in order to achieve this
behavior both ends look at the timer values in the received (initial)
adjacency message and agree to use the higher of the two values.
That is, the node that receives a higher timer value than its own,
will reply in its subsequent adjacency messages (such as SYNACK, ACK)
with the higher timer value.
The GSMP adjacency message defined in [RFC3292] is extended for ANCP 5.2. ANCP Based DSL Topology Discovery
and is shown in section 5.3 immediately following this section. The 5.2.1. Goals
8-bit "version" field in the adjacency protocol messages is modified
to carry the version and sub-version of the GSMP protocol for version
negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol.
[RFC Editor's note: sub-version needs to be changed from 1 to 2 upon
publication.] In the adjacency protocol the version and the sub-
version fields are used for version negotiation. The version
negotiation is performed before synchronisation is achieved. In a
SYN message the version/sub-version fields always contain the highest
version understood by the sender. A receiver receiving a SYN message
with a version/sub-version higher than understood will ignore that
message. A receiver receiving a SYN message with a version/
sub-vresion lower than its own highest version/sub-version, but a
version/sub-version that it understands, will reply with a SYNACK
with the version/sub-version from the received SYN in its ANCP
version/sub-version fields. This defines the version/sub-version of
the ANCP protocol to be used while the adjacency protocol remains
synchronised. All other messages will use the agreed version in the
version/sub-version fields.
The semantics and suggested values for Code, "Sender Name", "Receiver [TR_059] discusses various queuing/scheduling mechanisms to avoid
Name", "Sender Instance", and "Receiver Instance" fields are as congestion in the access network while dealing with multiple flows
defined in [RFC3292]. The "Sender Port", and "Receiver Port" should with distinct QoS requirements. Such mechanisms require that the NAS
be set to 0 by both ends. The pType field should be set to 0. The gains knowledge about the topology of the access network, the various
pFlag should be set to 1. links being used and their respective net data rates. Some of the
information required is somewhat dynamic in nature (e.g. DSL sync
rate, and therefore also the net data rate), hence cannot come from a
provisioning and/or inventory management OSS system. Some of the
information varies less frequently (e.g. capacity of a DSLAM uplink),
but nevertheless needs to be kept strictly in sync between the actual
capacity of the uplink and the image the NAS has of it.
If the adjacency times out on either end, due to not receiving an The following section describes ANCP messages that allow the Access
adjacency message for a duration of (3 * Timer value), where the Node (e.g., DSLAM) to communicate access network topology information
timer value is specified in the adjacency message, all the state and any corresponding updates to the NAS.
received from the ANCP neighbor should be cleaned up, and the TCP
connection should be closed. The NAS would continue to listen for
new connection requests. The DSLAM will try to re-establish the TCP
connection and both sides will attempt to re-establish the adjacency.
The handling defined above will need some modifications when ANCP Some of the parameters that can be communicated from the DSLAM to the
graceful restart procedures are defined. These procedures will be NAS include DSL line state, actual upstream and downstream net data
defined in a separate draft. rates of a synchronized DSL link, maximum attainable upstream and
downstream net data rates, interleaving delay etc. Topology
discovery is specifically important in case the net data rate of the
DSL line changes over time. The DSL net data rate may be different
every time the DSL modem is turned on. Additionally, during the time
the DSL modem is active, data rate changes can occur due to
environmental conditions (the DSL line can get "out of sync" and can
retrain to a lower value).
5.3. Capability negotiation 5.2.2. Message Flow
The adjacency message as defined in [RFC3292] is extended to carry To provide expected service levels, the NAS needs to learn the
"Capability TLVs". Both the NAS and the access node will advertise initial attributes of the DSL line before the subscriber can log in
supported capabilities in the originated adjacency messages. If a and access the services provisioned for the subscription. When a DSL
received adjacency message indicates absence of support for a line initially comes up or resynchronizes to a different rate, the
capability that is supported by the receiving device, it will turn DSLAM generates and transmits an ANCP Port UP Event message to the
off the capability locally and will send an updated adjacency message NAS. The extension field in the message carries the TLVs containing
with the capability turned off to match the received capability set. DSL line specific parameters. Upon loss of signal on the DSL line,
This process will eventually result in both sides agreeing on the an ANCP Port DOWN message is generated by the DSLAM and sent to the
minimal set of supported capabilities. The adjacency will not come NAS. Figure 7 summarizes the interaction.
up unless the capabilities advertised by the controller and the
controlled device match.
After initial synchronization, if at anytime a capability mismatch is 1. NAS ------------------------ Access ----- Home ----- Subscriber
detected, the adjacency will be brought down (RSTACK will be Node Gateway
generated by the device detecting the mismatch), and synchronization
will be re-attempted.
0 1 2 3 <----- Port UP(Event Message) <----- DSL
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 (default line parameters) Signal
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Sub | Message Type | Timer |M| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Receiver Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | PFlag | Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tech Type | # of TLVs | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 2. NAS ------------------------ Access ----- Home ----- Subscriber
Node Gateway
The format of capability TLV is: <----- Port UP (Event Message) <----- DSL
(updated line parameters) Resynch
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. NAS ------------------------ Access ----- Home ----- Subscriber
| Capability Type | Capability Length | Node Gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Capability TLV <--- Port DOWN (Event Message) <---- DSL
Loss of Signal
The Tech Type field type indicates the technology to which the Figure 7: ANCP Message Flow For DSL Topology Discovery
capability extension applies. For access node control in case of DSL
networks, new type "DSL" is proposed. The value for this field is
0x05. This is the first available value in the range that is not
currently allocated. It will need to be reserved with IANA.
Capability length is the number of actual bytes contained in the The Event message with Port UP message type (80) is used for
value portion of the TLV. The TLV is padded to a 4-octet alignment. conveying DSL line attributes to the NAS. This message with relevant
Therefore, a TLV with no data will contain a zero in the length field extensions is defined in the next section.
(if capability data is three octets, the length field will contain a
three, but the size of the actual TLV is eight octets). Capability
data field can be empty if the capability is just a boolean. In case
the capability is a boolean, it is inferred from the presence of the
TLV (with no data).
Capability data provides the flexibility to advertise more than mere 5.2.3. Specification of the ANCP DSL Topology Discovery Capability
presence or absence of a capability. Capability types can be
registered with IANA. Following capabilities are defined for ANCP as
applied to DSL access:
1. Capability Type : Dynamic-Topology-Discovery = 0x01 5.2.3.1. Protocol Requirements
Length (in bytes) : 0 The DSL topology discovery capability is assigned capability type
0x01. No capability data is associated with this capability.
Implementations of the DSL topology discovery capability MUST support
the following ANCP protocol elements:
Capability Data : NULL o ANCP Port UP and Port DOWN Event messages, which are based on the
GSMPv3 [RFC3292] messages of the same name but include capability-
specific modifications and extensions (Section 5.2.3.2).
2. Capability Type : Line-Configuration = 0x02 o The procedures associated with these messages and their contents
(Section 5.2.3.2.1).
Length (in bytes) : 0 o Access-Loop-Circuit-ID TLV;
Capability Data : NULL o Access-Loop-Remote-Id TLV;
3. Capability Type : Transactional-Multicast = 0x03 (controller i.e. o Access-Aggregation-Circuit-ID-Binary TLV;
NAS terminates IGMP messages from subscribers, and via l2 control o Access-Aggregation-Circuit-ID-ASCII TLV;
protocol, signals state to the access-nodes (e.g. DSLAMs) to
enable layer2 replication of multicast streams. In ATM access
network this implies that NAS instructs the access-node to setup
a P2MP cross-connect. The details of this will be covered in a
separate ID.
Length (in bytes) : 0 o DSL-Line-Attributes TLV;
Capability Data : NULL o DSL-Type TLV;
4. Capability Type : OAM = 0x04 o Actual-Net-Data-Upstream TLV;
Length (in bytes) : 0 o Actual-Net-Data-Rate-Downstream TLV;
Capability Data : NULL o Minimum-Net-Data-Rate-Upstream TLV;
5.4. GSMP Message Extensions for Access Node Control o Minimum-Net-Data-Rate-Downstream TLV;
5.4.1. General Extensions o Attainable-Net-Data-Rate-Upstream TLV;
Extensions to GSMP messages for various use-cases of "Access Node o Attainable-Net-Data-Rate-Downstream TLV;
Control" mechanism are defined in sections Section 5.4.2 to
Section 5.4.4. However, sub-sectionSection 5.4.1.1 below defines
extensions to GSMP that have general applicability and section
Section 5.4.5 introduces anothor messaging principle and additional
general purpose TLVs that could be used to develop new use cases in
future.
5.4.1.1. Extension TLV o Maximum-Net-Data-Rate-Upstream TLV;
In order to provide flexibility and extensibility certain GSMP o Maximum-Net-Data-Rate-Downstream TLV;
messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
[RFC3292] have been modified to include an extension block that
follows a TLV structure. Individual messages in the following
sections describe the usage and format of the extension block.
All Extension TLVs will be designated as follow: o Minimum-Net-Low-Power-Data-Rate-Upstream TLV;
o Minimum-Net-Low-Power-Data-Rate-Downstream TLV;
o Maximum-Interleaving-Delay-Upstream TLV;
o Maximum-Interleaving-Delay-Downstream TLV;
o Actual-Interleaving-Delay-Upstream TLV;
o Actual-Interleaving-Delay-Downstream TLV;
o DSL-line-state TLV;
o Access Loop Encapsulation TLV.
The TLVs listed above are specified in Section 5.2.3.3.
5.2.3.2. ANCP Port UP and Port DOWN Event Message Descriptions
The ANCP Port UP and Port DOWN Event messages are derived from the
GSMPv3 Event message shown in Section 9 of [RFC3292]. The modified
format used for DSL topology discovery is shown in Figure 8.
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 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Label +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ TLVs ~
~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Extension TLV Figure 8: Format Of the ANCP Port UP and Port DOWN Event Messages
For DSL Topology Discovery
x: Reserved Flags
These are generally used by specific messages and will be
defined in those messages.
Message Type
An 8-bit field corresponding to the message type where the
extension block is used.
Tech Type
An 8-bit field indicating the applicable technology type value. See Section 4.4 for a description of the ANCP general message header.
The Message Type plus the Tech Value uniquely define a single The Message Type field MUST be set to 80 for Port UP, 81 for Port
Extension Type and can be treated as a single 16 bit extension DOWN. The 12 bit Code field MUST be set to 0. The 4 bit Result
type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL field MUST be set to 0 (signifying Ignore). The 24-bit Transaction
technology and 0x01 for PON technology. Identifier field MUST be set to 0. Other fields in the general
header MUST be set as described in Section 4.4.
0x00 Extension block not in use The Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Topology Discovery capability and MUST be
considered reserved. The Label field (including the Stacked Label
Indicator and the unused flags at the start of the Label field), is
also unused, and MUST be treated as a reserved fixed 8-byte field.
The handling of unused/reserved fields is described in
Section 4.4.2.1.
0x01 PON The remaining message fields are described as follows:
0x05 DSL Extension Flags: The flag bits denoted by 'x' are currently
unspecified and reserved.
0x06 - 0xFE Reserved Message Type: Message Type has the same value as in the general
header (i.e., 80 or 81).
0xFF Base Specification Use Tech Type: MUST be set to 0x05 (DSL).
Block Length Block Length: unused, reserved.
A 8-bit field indicating the length of the Extension Value # of TLVs: the number of TLVs that follow, not counting TLVs
field in bytes. When the Tech Type = 0x00, the length value encapsulated within other TLVs.
MUST be set to 0.
Extension Value Extension Block Length: the total length of the TLVs carried in the
extension block in bytes, including any padding within individual
TLVs. (The existing "Block Length" field inherited from the GSMP
message is limited to 255 bytes and is not sufficient).
A variable length field that is an integer number of 32 bit TLVs: two or more TLVs to identify a DSL line and define its
words long. The Extension Value field is interpreted according characteristics.
to the specific definitions provided by the messages in the
following sections..
5.4.2. Topology Discovery Extensions 5.2.3.2.1. Procedures
The GSMP Event message with PORT UP message type (80) is used for The GSMP Event message with Port UP message type (80) is used for
conveying DSL line attributes to the NAS. The message SHOULD be conveying DSL line attributes to the NAS. The message SHOULD be
generated when a line first comes UP, or any of the attributes of the generated when a line first comes UP, or any of the attributes of the
line change e.g. the line re-trains to a different rate or one or line change e.g. the line re-trains to a different rate or one or
more of the configured line attributes are administratively modified. more of the configured line attributes are administratively modified.
Also, when the ANCP session first comes up, the DSLAM SHOULD transmit Also, when the ANCP session first comes up, the DSLAM SHOULD transmit
a PORT UP message to the NAS for each line that is up. When a DSL a Port UP message to the NAS for each line that is up. When a DSL
line goes down (idle or silent), the DSLAM SHOULD transmit an Event line goes down (idle or silent), the DSLAM SHOULD transmit an Event
message with PORT DOWN message type (81) to the NAS. It is message with Port DOWN message type (81) to the NAS. It is
recommended that the DSLAMs use a dampening mechanism per DSL line to recommended that the DSLAMs use a dampening mechanism per DSL line to
control the rate of state changes per DSL line, communicated to the control the rate of state changes per DSL line, communicated to the
NAS. NAS.
Not all the fields in GSMP Event message are applicable to ANCP. The If a Port UP message with a Result field set to 0 is received by the
fields that are not applicable MUST be set to zero by the ANCP sender NAS and the NAS is able to process the message correctly, the NAS
and ignored by the ANCP receiver. The fields in the PORT UP and PORT MUST NOT generate any ANCP message in response to the Port UP. If
DOWN messages to be set by the ANCP sender, and corresponding the Port UP message received cannot be processed correctly by the NAS
handling by the ANCP receiver is described below. (e.g. the message is malformed) the NAS MAY respond with an ANCP
Generic Response message (Section 6.1.3) containing the reason for
the failure.
The version field MUST be set to 3, and the sub field MUST be set to In the case of bonded copper loops to the customer premise (as per
1. As defined in [RFC3292], the one byte Message Type field MUST be the DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the
set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event DSLAM MUST report the aggregate net data rate and other attributes
Message. The 12 bit Code field MUST be set to 0. The 4 bit Result for the DSL bonded circuit (represented as a single logical port) to
field MUST be set to 0 (signifying Ignore.) If a PORT UP message the NAS in a Port UP message. Any change in the aggregate net data
with a Result field set to 0 is received by the NAS and the NAS is rate of the DSL bonded circuit (due to a change in net data rate of
able to process the message correctly, the NAS MUST NOT generate any individual constituent DSL lines or due to change in state of the
ANCP message in response to the PORT UP. If the PORT UP message individual constituent DSL lines) MUST be reported by the DSLAM to
received cannot be processed correctly by the NAS (e.g. the message the NAS in a Port UP message. The DSLAM MUST also report the
is malformed) the NAS MAY respond with an ANCP Error Message (TBD) aggregate state of the DSL bonded circuit to the NAS via Port UP and
containing the reason of the failure. The 24-bit Transaction Port DOWN messages.
Identifier field MUST be set to 0. The "I" bit and the SubMessage
field MUST be set to 1 to signify no fragmentation. The Length field
is two bytes and MUST contain the length of the message (including
header and the payload) in bytes.
The "Port" field, "Port Session Number" field and "Event Sequence The definition of TLVs in the next section contains some additional
Number" field are 4 bytes each, and MUST be set to 0 by the ANCP procedural information.
sender. LABEL field in event messages is defined as a TLV in
[RFC3292]. ANCP does NOT use the Label TLV. In both PORT UP and
PORT DOWN event messages an ANCP sender MUST treat the Label field,
immediately following the "Event Sequence Number" field, as a fixed 8
byte field, and MUST set these 8 bytes to 0. The receiver MUST NOT
interpret the LABEL field as a TLV and MUST ignore the 8 bytes
immediately following the "Event Sequence Number" field. In future
versions of ANCP, if necessary, the un-used fields in GSMP Event
message, which do not have ANCP specific semantics, can be used
partially or completely, by re-naming appropriately, and associating
valid semantics with these fields.
The Tech Type field is extended with new type "DSL". The value for 5.2.3.3. TLVs For DSL Topology Discovery
this field is 0x05.
In case of bonded copper loops to the customer premise (as per DSL The following TLVs are currently defined for DSL Topology Discovery,
multi-pair bonding described by [G.988.1] and [G.988.2]), the DSLAM but may be reused for other capabilities.
MUST report the aggregate net data rate and other attributes for the
"DSL bonded circuit" (represented as a single logical port) to the
NAS in a PORT UP message. Any change in the aggregate net data rate
of the "DSL bonded circuit" (due to a change in net data rate of
individual constituent DSL lines or due to change in state of the
individual constituent DSL lines) MUST be reported by the DSLAM to
the NAS in a PORT UP message. The DSLAM MUST also report the
"aggregate" state of the "DSL bonded circuit" to the NAS via PORT UP
and PORT DOWN messages.
0 1 2 3 5.2.3.3.1. Access-Loop-Circuit-ID TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Label +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 Name: Access-Loop-Circuit-ID
The format of the "Extension Value" field for Tech Type "DSL" is as Type: 0x0001
follows :
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 Description: an identifier of the subscriber's connection to the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Access Node (i.e. "local loop"). The local loop can be ATM based
| # of TLVs | Extension Block length (bytes) | or Ethernet based. The access loop circuit ID has local
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ significance at the Access Node. The exact usage on the NAS is
| | beyond the scope of this document. The format used for local loop
~ TLVs ~ identification in ANCP messages MUST be identical to what is used
~ ~ by the Access Nodes in subscriber signaling messages when the
| | Access Nodes act as signaling relay agents as outlined in
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [RFC3046] and [TR_101].
Figure 12: Extension Value For an ATM based local loop the string consists of slot/port and
VPI/VCI information corresponding to the subscriber's DSL
connection. Default ABNF [RFC5234] syntax for the string inserted
by the Access Node as per [TR_101] is:
The "Extension Value" contains one or more TLVs to identify a DSL Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci
line and define its characteristics. A TLV can consist of multiple
sub-TLVs. First 2 byte of the "Extension Value" contains the number
of TLVs that follow. The next 2 bytes contain the total length of
the TLVs carried in the extension block in bytes (existing "Block
Length" field in the GSMP message is limited to 255 bytes and is not
sufficient).
General format of a TLV is : where the meanings of the terms should be obvious from their
names.
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 The Access-Node-Identifier uniquely identifies the Access Node in
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the access network. The slot/port and VPI/VCI uniquely identify
| Type | Length | the DSL line on the Access Node. Also, there is one to one
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ correspondence between DSL line and the VC between the Access Node
| | and the NAS.
~ Value ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: General TLV For a local loop which is Ethernet based (and tagged), the string
consists of slot/port and VLAN tag corresponding to the
subscriber. Default ABNF syntax for the string inserted by the
Access Node as per [TR_101] is:
The value field in each TLV is padded to a 4-octet alignment. The Access-Node-Identifier " eth " slot "/" port [":" vlan-id]
Length field in each TLV contains the actual number of bytes in the
TLV (not including the padding if present). If a TLV is not
understood by the NAS, it is silently ignored. Currently defined
types start from 0x01.
Following TLVs are currently defined: This is a mandatory TLV.
1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and Length: up to 63 bytes
contains an identifier of the subscriber's connection to the
access node (i.e. "local loop"). The "local loop" can be ATM
based or Ethernet based. The "Access Loop Circuit ID" has local
significance at the access node. The exact usage on the NAS is
beyond the scope of this document. The format used for "local
loop" identification in ANCP messages MUST be identical to what
is used by the access nodes in subscriber signaling messages when
the access nodes act as "signaling relay agents" as outlined in
[RFC3046] and [TR-101].
Length : (up to 63 bytes) Value: ASCII string
Value : ASCII string 5.2.3.3.2. Access-Loop-Remote-Id TLV
For an ATM based local loop the string consists of slot/port Name: Access-Loop-Remote-Id
and VPI/VCI information corresponding to the subscriber's DSL
connection. Default syntax for the string inserted by the
access node as per [TR-101] is:
"Access-Node-Identifier atm slot/port:vpi.vci" Type: 0x0002
The Access-Node-Identifier uniquely identifies the access node Description: This is an optional TLV and contains an identifier to
in the access network. The slot/port and VPI/VCI uniquely uniquely identify a user on a local loop on the Access Node. The
identifies the DSL line on the access node. Also, there is exact usage on the NAS is out of scope of this document. It is
one to one correspondence between DSL line and the VC between desirable that the format used for the field be similar to what is
the access node and the NAS. used by the Access Nodes in subscriber signaling messages when the
Access Nodes act as signaling relay agents as outlined in
[RFC3046] and [TR_101].
For local loop which is Ethernet based (and tagged), the Length: up to 63 bytes
string consists of slot/port and VLAN tag corresponding to the
subscriber. Default syntax for the string inserted by the
access node as per [TR-101] is:
"Access-Node-Identifier eth slot/port[:vlan-id]" Value: ASCII string
2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and 5.2.3.3.3. Access-Aggregation-Circuit-ID-Binary TLV
contains an identifier to uniquely identify a user on a local
loop on the access node. The exact usage on the NAS is out of
scope of this document. It is desirable that the format used for
the field is similar to what is used by the access nodes in
subscriber signaling messages when the access nodes act as
"signaling relay agents" as outlined in [RFC3046] and [TR-101].
Length : (up to 63 bytes) Name: Access-Aggregation-Circuit-ID-Binary
Value : ASCII string Type: 0x0006
3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) Description: For ethernet access aggregation, where a per-subscriber
(stacked) VLAN can be applied (1:1 model defined in [TR_101]), the
VLAN stack provides a convenient way to uniquely identify the DSL
line. The outer VLAN is equivalent to virtual path between a
DSLAM and the NAS and inner VLAN is equivalent to a virtual
circuit on a per DSL line basis. In this scenario, any subscriber
data received by the Access Node and transmitted out the uplink to
the aggregation network will be tagged with the VLAN stack
assigned by the Access Node.
Length : (8 bytes) This TLV carries the VLAN tags assigned by the access node in the
ANCP messages. The VLAN tags can uniquely identify the DSL line
being referred to in the ANCP messages, assuming the VLAN tags are
not in any way translated in the aggregation network and are
unique across physical ports. Each 32 bit unsigned integer (least
significant bits) contains a 12 bit VLAN identifier (which is part
of the VLAN tag defined by IEEE 802.1Q).
Value : two 32 bit integers [Editor's Note: should we specify that the upper 20 bits are set
to zero? Which one is inner, which one is outer?]
For ethernet access aggregation, where a per-subscriber Also, in case of an ATM aggregation network, where the DSLAM is
(stacked) VLAN can be applied (1:1 model defined in [TR-101]), directly connected to the NAS (without an intermediate ATM
the VLAN stack provides a convenient way to uniquely identify switch), the two values can contain VPI and VCI on the DSLAM
the DSL line. The outer VLAN is equivalent to virtual path uplink (and can uniquely identify the DSL line on the DSLAM).
between a DSLAM and the NAS and inner VLAN is equivalent to a
virtual circuit on a per DSL line basis. In this scenario,
any subscriber data received by the access node and
transmitted out the uplink to the aggregation network will be
tagged with the VLAN stack assigned by the access node
This TLV can carry the VLAN tags assigned by the access node This TLV is optional.
in the ANCP messages. The VLAN tags can uniquely identify the
DSL line being referred to in the ANCP messages, assuming the
VLAN tags are not in any way translated in the aggregation
network and are unique across physical ports. Each 32 bit
integer (least significant bits) contains a 12 bit VLAN
identifier (which is part of the VLAN tag defined by IEEE
802.1Q).
Also, in case of an ATM aggregation network, where the DSLAM Length: 8 bytes
is directly connected to the NAS (without an intermediate ATM
switch), the two values can contain VPI and VCI on the DSLAM
uplink (and can uniquely identify the DSL line on the DSLAM).
This is optional. Value: two 32 bit unsigned integers
4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) 5.2.3.3.4. Access-Aggregation-Circuit-ID-ASCII TLV
Length : (up to 63 bytes) Name: Access-Aggregation-Circuit-ID-ASCII
Value : ASCII string Type: 0x0003
This field contains information pertaining to an uplink on the Description: This field contains information pertaining to an uplink
access node. For Ethernet access aggregation, assuming the on the Access Node. For Ethernet access aggregation, assuming the
access node assigns VLAN tags (1:1 model), typical format for Access Node assigns VLAN tags (1:1 model), typical ABNF format for
the string is: the string is:
"Access-Node-Identifier eth slot/port [:inner-vlan- Access-Node-Identifier " eth " slot "/" port [":"
id][:outer-vlan-id]" inner-vlan-id] [":" outer-vlan-id]
The slot/port corresponds to the ethernet uplink on the access The slot/port corresponds to the ethernet uplink on the Access
node towards the NAS. Node towards the NAS.
For an ATM aggregation network, typical format for the string For an ATM aggregation network, the typical format for the string
is: is:
"Access-Node-Identifier atm slot/port:vpi.vci" Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci
This TLV allows the NAS to associate the information contained This TLV allows the NAS to associate the information contained in
in the ANCP messages to the DSL line on the access node. the ANCP messages to the DSL line on the Access Node.
If the access node inserts this string in the ANCP messages, If the Access Node inserts this string in the ANCP messages, when
when referring to local loop characteristics (e.g. DSL line referring to local loop characteristics (e.g. DSL line in case of
in case of a DSLAM), then it should be able to map the a DSLAM), then it should be able to map the information contained
information contained in the string uniquely to the local loop in the string uniquely to the local loop (e.g. DSL line).
(e.g. DSL line).
On the NAS, the information contained in this string can be On the NAS, the information contained in this string can be used
used to derive an "aggregation network" facing construct (e.g. to derive an aggregation-network-facing construct (e.g. an IP
an IP interface) corresponding to the local loop (e.g. DSL interface) corresponding to the local loop (e.g. DSL line). The
line). The association could be based on "local association could be based on local configuration on the NAS.
configuration" on the NAS.
The access node can also convey to the NAS, the The Access Node can also convey to the NAS the characteristics
characteristics (e.g. bandwidth) of the uplink on the access (e.g., bandwidth) of the uplink on the Access Node. This TLV then
node. This TLV then serves the purpose of uniquely serves the purpose of uniquely identifying the uplink whose
identifying the uplink whose characteristics are being characteristics are being defined. This version of the present
defined. A separate set of sub-TLVs will be defined for the document does not specify the TLVs needed to convey the uplink
uplink characteristics (TBD). characteristics, in the same way that the DSL-Line-Attributes TLV
and the TLVs encapsulated within it convey the characteristics of
the subscriber access line.
This TLV is optional. This TLV is optional.
5. Type (DSL Line Attributes = 0x04): Length: up to 63 bytes
Length : variable (up to 1024 bytes) Value: ASCII string
Value : This is a mandatory TLV and consists of one or more 5.2.3.3.5. DSL-Line-Attributes TLV (Mandatory)
Sub-TLVs corresponding to DSL line attributes. No sub-TLVs
other than the "DSL type" and "DSL line state" SHOULD be
included in a PORT DOWN message.
The general format of the sub-TLVs is identical to the general Name: DSL-Line-Attributes
TLV format. The value field in each sub-TLV is padded to a
4-octet alignment. The Length field in each sub-TLV contains
the actual number of bytes in the TLV (not including the
padding if present). Current defined sub-TLV types are start
from 0x81.
Following sub-TLVs are currently defined : Type: 0x0004
+ Type (DSL-Type = 0x91) : Defines the type of transmission Description: This is a mandatory TLV providing attribute values for
system in use. This is a mandatory TLV. a DSL line serving a subscriber.
Length : (4 bytes) Length: variable (up to 1024 bytes)
Value : (Transmission system : ADSL1 = 0x01, ADSL2 = Value: one or more encapsulated TLVs corresponding to DSL line
0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = attributes. The DSL-Line-Attributes TLV MUST contain the
0x06, UNKNOWN = 0x07). mandatory TLVs described below when it is present in a Port UP
message. It MAY contain the optional TLVs described below when it
is present in a Port UP message.
+ Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net When the DSL-Line-Attributes TLV is present in a Port DOWN message
data rate on a DSL line. This is a mandatory TLV. it SHOULD NOT include any TLVs other than DSL-Type and DSL-Line-
State.
Length : (4 bytes) 5.2.3.3.6. TLVs Delivering Line Attributes
Value : (Rate in Kb/sec) The TLVs which follow convey DSL line attributes. They MUST be
encapsulated within the DSL-Line-Attributes TLV when they are carried
in a Port UP or Port DOWN message.
+ Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual 5.2.3.3.6.1. DSL-Type TLV (Mandatory)
downstream net data rate on a DSL line. This is a
mandatory TLV.
Length : (4 bytes) Name: DSL-Type
Value : (Rate in Kb/sec) Type: 0x0091
+ Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net Description: Indicates the type of transmission system in use. This
data rate desired by the operator. This is optional. is a mandatory TLV.
Length : (4 bytes) Length: 4 bytes
Value : (Rate in Kb/sec) Value: 32 bit unsigned integer
+ Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum ADSL1 = 1
net data rate desired by the operator. This is optional.
Length : (4 bytes) ADSL2 = 2
Value : (Rate in Kb/sec) ADSL2+ = 3
+ Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum VDSL1 = 4
net upstream rate that can be attained on the DSL line.
This is an optional TLV.
Length : (4 bytes) VDSL2 = 5
Value : (Rate in Kb/sec) SDSL = 6
+ Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum UNKNOWN = 7
net downstream rate that can be attained on the DSL line.
This is an optional TLV.
Length : (4 bytes) 5.2.3.3.6.2. Actual-Net-Data-Rate-Upstream TLV
Value : (Rate in Kb/sec) Name: Actual-Net-Data-Rate-Upstream
+ Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net Type: 0x0081
data rate desired by the operator. This is optional.
Length : (4 bytes) Description: Actual upstream net data rate on a DSL line. This is a
mandatory TLV.
Value : (Rate in Kb/sec) Length: 4 bytes
+ Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum Value: Rate in Kbits/s as a 32 bit unsigned integer
net data rate desired by the operator. This is optional.
Length : (4 bytes) 5.2.3.3.6.3. Actual-Net-Data-Rate-Downstream TLV
Value : (Rate in Kb/sec)
+ Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) : Name: Actual-Net-Data-Rate-Downstream
Minimum net data rate desired by the operator in low power
state. This is optional.
Length : (4 bytes) Type: 0x0082
Value : (Rate in Kb/sec) Description: Actual downstream net data rate on a DSL line. This is
a mandatory TLV.
+ Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) : Length: 4 bytes
Minimum net data rate desired by the operator in low power
state. This is optional.
Length : (4 bytes) Value: Rate in Kbits/s as a 32 bit unsigned integer
Value : (Rate in Kb/sec) 5.2.3.3.6.4. Minimum-Net-Data-Rate-Upstream TLV
+ Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum Name: Minimum-Net-Data-Rate-Upstream
one way interleaving delay. This is optional.
Length : (4 bytes) Type: 0x0083
Value : (Time in msec) Description: Minimum upstream net data rate desired by the operator.
This is an optional TLV.
+ Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value Length: 4 bytes
corresponding to the interleaver setting. This is
optional.
Length : (4 bytes) Value: Rate in Kbits/s as a 32 bit unsigned integer
Value : (Time in msec) 5.2.3.3.6.5. Minimum-Net-Data-Rate-Downstream TLV
+ Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : Name: Minimum-Net-Data-Rate-Downstream
maximum one way interleaving delay. This is optional.
Length : (4 bytes) Type: 0x0084
Value : (Time in msec) Description: Minimum downstream net data rate desired by the
operator. This is an optional TLV.
+ Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value Length: 4 bytes
corresponding to the interleaver setting. This is
optional.
Length : (4 bytes) Value: Rate in Kbits/s as a 32 bit unsigned integer
Value : (Time in msec)
+ Type (DSL line state = 0x8F) : The state of the DSL line. 5.2.3.3.6.6. Attainable-Net-Data-Rate-Upstream TLV
For PORT UP message, at this time, the TLV is optional
(since the message type implicitly conveys the state of the
line). For PORT DOWN, the TLV is mandatory, since it
further communicates the state of the line as IDLE or
SILENT.
Length : (4 bytes) Name: Attainable-Net-Data-Rate-Upstream
Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } Type: 0x0085
Description: Maximum net upstream rate that can be attained on the
DSL line. This is an optional TLV.
+ Type (Access Loop Encapsulation = 0x90) : The data link Length: 4 bytes
protocol and, optionally the encapsulation overhead on the
access loop. This is an optional TLV. However, when this
TLV is present, the data link protocol MUST minimally be
indicated. The encapsulation overhead can be optionally
indicated.
Length : (3 bytes) Value: Rate in Kbits/s as a 32 bit unsigned integer
Value : The three bytes (most to least significant) and 5.2.3.3.6.7. Attainable-Net-Data-Rate-Downstream TLV
valid set of values for each byte are defined below.
Data Link (1 byte): {ATM AAL5 = 0, ETHERNET = 1} Name: Attainable-Net-Data-Rate-Downstream
Encaps 1 (1 byte): { Type: 0x0086
NA = 0, Description: Maximum net downstream rate that can be attained on the
DSL line. This is an optional TLV.
Untagged Ethernet = 1, Length: 4 bytes
Single-tagged Ethernet = 2} Value: Rate in Kbits/s as a 32 bit unsigned integer
Encaps 2 (1 byte):{ 5.2.3.3.6.8. Maximum-Net-Data-Rate-Upstream TLV
NA = 0, Name: Maximum-Net-Data-Rate-Upstream
PPPoA LLC = 1 Type: 0x0087
PPPoA NULL = 2, Description: Maximum net upstream data rate desired by the operator.
This is an optional TLV.
IPoA LLC = 3, Length: 4 bytes
IPoA NuLL = 4,
Ethernet over AAL5 LLC with FCS = 5, Value: Rate in Kbits/s as a 32 bit unsigned integer
Ethernet over AAL5 LLC without FCS = 6, 5.2.3.3.6.9. Maximum-Net-Data-Rate-Downstream TLV
Ethernet over AAL5 NULL with FCS = 7, Name: Maximum-Net-Data-Rate-Downstream
Ethernet over AAL5 NULL without FCS = 8} Type: 0x0088
If this TLV is present, the Data Link protocol MUST be Description: Maximum net downstream data rate desired by the
indicated as defined above. However, the Access Node can operator. This is an optional TLV.
choose to not convey the encapsulation on the access loop
by specifying a value of 0 (NA) for the two encapsulation
fields
5.4.3. Line Configuration Extensions Length: 4 bytes
The Port Management message format defined in [RFC3292] has been Value: Rate in Kbits/s as a 32 bit unsigned integer
modified to contain an extension block (described above in section
Section 5.4.1.1) at the end of the message. Also, the original two
byte Function field has been modified to contain one byte for the
Function field indicating a specific action to be taken by the
recipient of the message, and one byte for X-Function field, which
could further qualify the action specified in the Function field.
Any Function specific data MUST be carried in the extension block.
Not all the fields in GSMP Port Management message are applicable to 5.2.3.3.6.10. Minimum-Net-Low-Power-Data-Rate-Upstream TLV
ANCP. The fields that are not applicable MUST be set to zero by the
ANCP sender and ignored by the ANCP receiver.
The NAS uses the extension block in the Port Management messages to Name: Minimum-Net-Low-Power-Data-Rate-Upstream
convey service attributes of the DSL lines to the DSLAM. TLVs are
defined for DSL line identification and service data for the DSL Type: 0x0089
lines. Port number is set to 0 in the message. A new action type
"Configure Connection Service Data" (value 0x8) is defined. The Description: Minimum net upstream data rate desired by the operator
"Function" field is set to the action type. This action type in low power state. This is an optional TLV.
indicates to the device being controlled (Access Node i.e. DSLAM) to
apply service configuration data contained in the extension value Length: 4 bytes
(TLVs), to the DSL line (identified by one of the TLVs in the
extension value). For the action type "Configure Connection Service Value: Rate in Kbits/s as a 32 bit unsigned integer
Data", X-Function field MUST be set to 0. The Tech Type field is
extended with new type "DSL". The value for this field is 0x05. 5.2.3.3.6.11. Minimum-Net-Low-Power-Data-Rate-Downstream TLV
Name: Minimum-Net-Low-Power-Data-Rate-Downstream
Type: 0x008A
Description: Minimum net downstream data rate desired by the
operator in low power state. This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.12. Maximum-Interleaving-Delay-Upstream TLV
Name: Maximum-Interleaving-Delay-Upstream
Type: 0x008B
Description: maximum one way interleaving delay. This is an
optional TLV.
Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.13. Actual-Interleaving-Delay-Upstream TLV
Name: Actual-Interleaving-Delay-Upstream
Type: 0x008C
Description: Value corresponding to the interleaver setting. This
is an optional TLV.
Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.14. Maximum-Interleaving-Delay-Downstream TLV
Name: Maximum-Interleaving-Delay-Downstream
Type: 0x008D
Description: maximum one way interleaving delay. This is an
optional TLV.
Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.15. Actual-Interleaving-Delay-Downstream
Name: Actual-Interleaving-Delay-Downstream
Type: 0x008E
Description: Value corresponding to the interleaver setting. This
is an optional TLV.
Length: 4 bytes
Value: Time in ms as a 32 bit unsigned integer
5.2.3.3.6.16. DSL-Line-State TLV (Mandatory for Port DOWN)
Name: DSL-Line-State
Type: 0x008F
Description: The state of the DSL line. For the Port UP message, in
this specification, the TLV is optional (since the message type
implicitly conveys the state of the line). For Port DOWN, the TLV
is mandatory, since it further communicates the state of the line
as IDLE or SILENT.
Length: 4 bytes
Value: 32 bit unsigned integer
SHOWTIME = 1
IDLE = 2
SILENT = 3
5.2.3.3.6.17. Access-Loop-Encapsulation TLV
Name: Access-Loop-Encapsulation
Type: 0x0090
Description: The data link protocol and, optionally, the
encapsulation overhead on the access loop. This is an optional
TLV. However, when this TLV is present, the data link protocol
MUST minimally be indicated. The encapsulation overhead MAY be
indicated. The Access Node can choose to not convey the
encapsulation on the access loop by specifying a value of 0 (NA)
for the two encapsulation fields
Length: 3 bytes
Value: The three bytes (most to least significant) and valid set of
values for each byte are defined below.
Byte 1: Data Link
ATM AAL5 = 0
ETHERNET = 1
Byte 2: Encapsulation 1
NA = 0
Untagged Ethernet = 1
Single-tagged Ethernet = 2
Byte 3: Encapsulation 2
NA = 0
PPPoA LLC = 1
PPPoA NULL = 2
IPoA LLC = 3
IPoA NuLL = 4
Ethernet over AAL5 LLC with FCS = 5
Ethernet over AAL5 LLC without FCS = 6
Ethernet over AAL5 NULL with FCS = 7
Ethernet over AAL5 NULL without FCS = 8
The Access-Loop-Encapsulation TLV is illustrated in Figure 9.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Access-Loop-Encapsulation TLV
5.3. ANCP based DSL Line Configuration
5.3.1. Goals
Following dynamic discovery of access topology (identification of DSL
line and its attributes) as assisted by the mechanism described in
the previous section (topology discovery), the NAS may query a
subscriber management OSS system (e.g., RADIUS server) to retrieve
subscriber authorization data (service profiles). Most of such
service mechanisms are typically enforced by the NAS itself, but
there are a few cases where it may be useful to push such service
parameters to the DSLAM for local enforcement of a mechanism (e.g.
DSL-related) on the corresponding subscriber line.
One such example of a service parameter that can be pushed to the
DSLAM for local enforcement is DSL "interleaving delay". Longer
interleaving delay (and hence stringent error correction) is required
for a video service to ensure better video "quality of experience",
whereas for a VoIP service or for "shoot first" gaming service, a
very short interleaving delay is more appropriate. Another relevant
application is downloading per subscriber multicast channel
entitlement information in IPTV applications where the DSLAM is
performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS
can achieve the goal of pushing line configuration to the DSLAM by an
interoperable and standardized protocol.
If a subscriber wants to choose a different service, it can require
an operational-expense-intensive reconfiguration of the line via a
network operator, possibly implying a business-to-business
transaction between an ISP and an access provider. Using ANCP for
line configuration from the NAS dramatically simplifies the OSS
infrastructure for service management, allowing fully centralized
subscriber-related service data (e.g., RADIUS server back-end) and
avoiding complex cross-organization business-to-business
interactions.
The best way to change line parameters is by using profiles. These
profiles (DSL profiles for different services) are pre-configured on
the DSLAMs. The NAS can then send a reference to the right DSL
profile via ANCP. Alternatively, discrete DSL parameters can also be
conveyed by the NAS in ANCP.
5.3.2. Message Flow
Triggered by topology information reporting a new DSL line or
triggered by a subsequent user session establishment (PPP or DHCP),
the NAS may send line configuration information (e.g. reference to a
DSL profile) to the DSLAM using ANCP Port Management messages. The
NAS may get such line configuration data from a policy server (e.g.,
RADIUS). Figure 10 summarizes the interaction.
+----------+ +-----+ +-----+ +-------+ +-----------+
|Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber |
|Policy | +-----+ +-----+ |Gateway| +-----------+
|Server | +-------+
+----------+
1.DSL Signal
<-----------
2. Port UP (Event Message)
(Access Topology Discovery)
<----------------
3. PPP/DHCP Session
<--------------------------------
4. Authorization
& Authentication
<-------------------
Port Management Message
(Line Configuration)
5. -------->
Figure 10: Message Flow - ANCP Mapping For Initial Line Configuration
The NAS may update the line configuration due to a subscriber service
change (e.g. triggered by the policy server). Figure 11 summarizes
the interaction.
+------+ +-------+ +---------+ +----------+
| NAS |-----| AN |---| Home |--|Subscriber|
+------+ +-------+ | Gateway | +----------+
+---------+
1. PPP/DHCP Session
<------------------------------------------
+-----------+ 2. Service On Demand
| |<-----------------------------------------------
| Web portal|
| OSS etc | 3.Change of
| | Authorization
|Radius AAA | --------> 4.Port Management
| Policy | Message
| | ------------->
+-----------+ (Updated Line Config - New Profile)
Figure 11: Message flow - ANCP Mapping For Updated Line Configuration
The format of relevant extensions to port management message is
defined in section Section 5.3.3. The line configuration models
could be viewed as a form of delegation of authorization from the NAS
to the DSLAM.
5.3.3. Specification of the ANCP DSL Line Configuration Capability
5.3.3.1. Protocol Requirements
The DSL line configuration capability is assigned capability type
0x02. No capability data is associated with this capability.
Implementations of the DSL line configuration capability MUST support
the following ANCP protocol elements:
o ANCP Port Management message, which is based on the GSMPv3
[RFC3292] message of the same name but includes capability-
specific modifications and extensions (Section 5.3.3.2).
o The procedures associated with this message and its contents
(Section 5.3.3.3).
o Access-Loop-Circuit-ID TLV (as defined in Section 5.2.3.3);
o Access-Aggregation-Circuit-ID-Binary TLV (as defined in
Section 5.2.3.3);
o Access-Aggregation-Circuit-ID-ASCII TLV (as defined in
Section 5.2.3.3);
o Service-Profile-Name TLV (as defined in Section 5.3.3.4).
5.3.3.2. ANCP Port Management Message Format For DSL Line Configuration
The ANCP Port Management message for DSL line configuration has the
format shown in Figure 12.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code | | TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | | ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number | | Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number | | Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration | Function | X-Function | |R|x|x|x|x|x|x|x| Duration | Function | X-Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags | | Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 Figure 12
The format of the "Extension Value" field is as follows:
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 See Section 4.4 for a description of the ANCP general message header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type field MUST be set to 32. The 12 bit Code field MUST
| # of TLVs | Extension Block length (bytes) | 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
| | Transaction Identifier field MUST be set to a positive value. Other
~ TLVs ~ fields in the general header MUST be set as described in Section 4.4.
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Extension Value The Port Management message format defined in [RFC3292] has been
modified to contain additional data at the end of the message. Also,
the original two byte Function field has been modified to contain one
byte for the Function field indicating a specific action to be taken
by the recipient of the message, and one byte for X-Function field,
which further qualifies the action specified in the Function field.
Any Function specific data MUST be carried in TLVs in the extension
block.
The "Extension Value" field contains one or more TLVs containing DSL The Port, Port Session Number, and Event Sequence Number fields are
line identifier and desired service attributes of the the DSL line. not used by the DSL Line Configuration capability and MUST be
First 2 byte of the "Extension Value" contains the number of TLVs considered reserved. The handling of unused/reserved fields is
that follow. The next 2 bytes contain the total length of the described in Section 4.4.2.1.
extension block in bytes (existing "Block Length" field in the GSMP
message is limited to 255 bytes and is not sufficient).
General format of a TLV is: The remaining message fields are described as follows:
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 R Flag: not used by ANCP.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: General TLV Additional Port Management flags: the flag bits marked 'x' following
the R flag are not used by ANCP.
The value field is padded to a 4-octet alignment. The Length field Duration: not used for DSL line configuration.
in each TLV contains the actual number of bytes in the TLV (not
including the padding if present). If a TLV is not understood by the
access-node, it is silently ignored. Depending upon the deployment
scenario, the NAS may specify "Access Loop Circuit-ID" or the "Access
Aggregation Circuit-ID") as defined in section Section 5.4.1.
Following TLVs can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section Function: action to be performed. For DSL line configuration,
Section 5.4.1 Function MUST be set to 8 (Configure Connection Service Data).
This action type requests the Access Node (i.e., DSLAM) to apply
service configuration data contained in the extension value (TLVs)
to the DSL line (identified by one of the TLVs in the extension
value).
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in X-Function: qualifies the action set by Function. For DSL line
section Section 5.4.1 configuration, this field MUST be set to 0.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in Event Flags: not used by ANCP.
section Section 5.4.1
o Type (Service-Profile-Name = 0x05): Reference to a pre-configured Flow Control Flags: not used by ANCP.
profile on the DSLAM that contains service specific data for the
subscriber.
Length : (up to 64 bytes) Extension Flags: the flag bits denoted by 'x' before the Message
Type field are reserved for future use.
Value : ASCII string containing the profile name (NAS learns Message Type: Message Type has the same value as in the general
from a policy server after a subscriber is authorized). header (i.e., 32).
In future, more TLVs MAY be defined for individual service Tech Type: MUST be set to 0x05 (DSL).
attributes of a DSL line (e.g. rates, interleaving delay,
multicast channel entitlement access-list etc)
5.4.3.1. Provisioning Message Block Length: unused, reserved.
The Provisioning message is sent by the NAS to the AN to provision # of TLVs: the number of TLVs that follow, not counting TLVs
information in the AN. This message can be used to provision global encapsulated within other TLVs.
scope information on the Access Node.
The Message Type for the Provisioning message is 93. Extension Block Length: the total length of the TLVs carried in the
extension block in bytes, including any padding within individual
TLVs. (The existing "Block Length" field inherited from the GSMP
message is limited to 255 bytes and is not sufficient).
The NAS sending the Provisioning message MUST set the Result field to TLVs: two or more TLVs to identify a DSL line and configure its
0x00. service data.
The NAS MUST populate the ANCP Transaction Identifier field with a 5.3.3.3. Procedures
distinct non-zero, linearly incrementing value for each request per
adjacency, as described in Section 5.4.5 .
The ANCP Provisioning message payload MAY contain different TLVs, Section 5.3.2 Describes the circumstances under which the NAS sends a
like for example Service-Profile-Name TLV. The Service-Profile-Name Port Management message to the AN to configure DSL service parameters
TLV MAY appear zero, one or multiple times. for a specific subscriber line. To identify the line, the NAS MUST
include one of Access-Loop-Circuit-ID TLV, Access-Aggregation-
Circuit-ID-Binary TLV, or Access-Aggregation-Circuit-ID-ASCII TLV in
the Port Management message, depending upon the deployment scenario.
The NAS MUST include one or more TLVs to configure line service
parameters for that line. Section 5.3.3.4 currently identifies only
one such TLV, Service-Profile-Name, but other TLVs may be added by
extensions to ANCP.
On receipt of the Provisioning message, the AN MUST: If the NAS sets Result to AckAll (0x1) and the AN processes the Port
Management message successfully, the AN MUST return a Port Management
message in reply, containing a Result field set to Success (0x3).
All other fields of the returned message MUST be identical to those
received in the request.
o ignore the Result field If an error occurs during the processing of the Port Management
message, then the AN MUST always return a Port Management message
with the Result field set to Failure (0x4). The Code field MUST be
set to indicate the reason for failure. The remainder of the message
MUST be copied from the request. The AN MAY add a Status-Info TLV
(Section 6.2.3) to provide further information on the error, in which
case the various length fields and the # of TLVs field within the
message MUST be adjusted accordingly.
o if the AN can process the message successfully and accept all the 5.3.3.4. TLVs For DSL Line Configuration
provisioning directives contained in it, the AN MUST NOT send any
response.
5.4.4. OAM Extensions Currently only the following TLV is specified for DSL line
configuration. More TLVs may be defined in a future version of this
specification or in ANCP extensions for individual service attributes
of a DSL line (e.g. rates, interleaving delay, multicast channel
entitlement access-list).
GSMP "Port Management" message (type 32) SHOULD be used by the NAS to Name: Service-Profile-Name
trigger access node to run a loopback test on the local loop. The
message format is defined in section Section 5.4.2. The version
field SHOULD be set to 3 and sub-version field SHOULD be set to 1.
The remaining fields in the GSMP header have standard semantics. The
function type used in the request message SHOULD be set to "remote
loopback" (type = 0x09). The port, "port session number", "event
sequence number", duration, "event flags", "flow control flags" and
code fields SHOULD all be set to 0. The result field SHOULD be set
to "AckAll" to indicate requirement for the access node to send a
success or failure response. The transaction ID SHOULD contain a
sequence number inserted by the NAS in each request that it
generates.
Not all the fields in GSMP Port Management message are applicable to Type: 0x0005
ANCP. The fields that are not applicable MUST be set to zero by the
ANCP sender and ignored by the ANCP receiver.
The extension field format is also defined above in section Description: Reference to a pre-configured profile on the DSLAM that
Section 5.4.2. The extension value field can contain one or more contains service specific data for the subscriber.
TLVs including the access-line identifier on the DSLAM and OAM test
characteristics desired by the NAS.
The TLV format is defined above in section Section 5.4.2. The value Length: up to 64 bytes
field is padded to a 4-octet alignment. The Length field in each TLV Value: ASCII string containing the profile name (which the NAS
contains the actual number of bytes in the TLV (not including the learns from a policy server after a subscriber is authorized).
padding if present). If a TLV is not understood by the NAS, it is
silently ignored. Depending upon the deployment scenario, the NAS
may specify "Access Loop Circuit-ID" or the "Access Aggregation
Circuit-ID") as defined in section Section 5.4.1. Following TLVs can
appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4. ANCP Based DSL Line Testing Capability
Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in In a mixed Ethernet and ATM access network (including the local
section Section 5.4.1 loop), it is desirable to provide similar mechanisms for connectivity
checks and fault isolation, as those used in an ATM based
architecture. This can be achieved using an ANCP based mechanism
until end-to-end Ethernet OAM mechanisms are more widely implemented
in various network elements.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in A simple solution based on ANCP can provide the NAS with an access
section Section 5.4.1 line test capability and to some extent fault isolation. Controlled
by a local management interface the NAS can use an ANCP operation to
trigger the Access Node to perform a loopback test on the local loop
(between the Access Node and the CPE). The Access Node can respond
via another ANCP operation with the result of the triggered loopback
test. In the case of ATM based local loop the ANCP operation can
trigger the Access Node to generate ATM (F4/F5) loopback cells on the
local loop. In the case of Ethernet, the Access Node can trigger an
Ethernet loopback message(per EFM OAM) on the local loop.
o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to 5.4.1. Message Flow
loopback test. This is an optional TLV. If this TLV is not
present in the request message, the DSLAM SHOULD use locally
determined default values for the test parameters.
Length : (4 bytes) The Port Management message can be used by the NAS to request Access
Node to trigger a remote loopback test on the local loop. The result
of the loopback test can be asynchronously conveyed by the Access
Node to the NAS in a Port Management response message. The formats
of the relevant extensions to the Port Management message are defined
in Section 5.4.2.2. Figure 13 summarizes the interaction.
Value : two 1 byte numbers described below (listed in order of +-------------+ +-----+ +-------+ +----------------+
most to least significant). Thus, the 4 bytes consist of 1 |Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE |
byte of Count, followed by 1 byte of Timeout, followed by two |Policy Server| +-----+ +-------+ | (DSL Modem + |
pad bytes of zero. +-------------+ |Routing Gateway)|
+----------------+
Port Management Message
(Remote Loopback ATM loopback
Trigger Request) OR EFM Loopback
1. ----------------> 2. --------->
<--------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
+ Count (1 byte) : Number of loopback cells/messages that Figure 13: Message Flow For ANCP based OAM
should be generated on the local loop as part of the
loopback test. The NAS SHOULD restrict the "count" to be
greater than 0 and less than or equal to 32. The DSLAM
SHOULD discard the request for a loopback test, if the
received test parameters contain an out of range value for
the "count" field. The DSLAM MAY optionally send a failure
response to the NAS with the code "invalid test parameter".
+ Timeout (1 byte) : Upper bound on the time in seconds that 5.4.2. Specification of the ANCP DSL Line Testing Capability
the NAS would wait for a response from the DSLAM. If the
total time taken by the DSLAM to complete a test with
requested parameters, exceeds the specified "timeout" value,
it can choose to omit the generation of a response to the
NAS. DSLAM SHOULD use a locally determined value for the
"timeout", if the received value of the "timeout" parameter
is 0.
o Type (Opaque-Data = 0x08) : This is an optional TLV. If present 5.4.2.1. Protocol Requirements
in the request message, the DSLAM SHOULD reflect it back in the
response unmodified
Length : (8 bytes) The DSL line testing capability is assigned capability type 0x04. No
capability data is associated with this capability. Implementations
of the DSL line testing capability MUST support the following ANCP
protocol elements:
Value : Two 32 bit integers inserted by the NAS (not to be o ANCP Port Management message, which is based on the GSMPv3
interpreted by the DSLAM, but just reflected back in the [RFC3292] message of the same name but includes capability-
response). specific modifications and extensions (Section 5.4.2.2).
The access node generates a success or failure response when it deems o The procedures associated with this message and its contents
the loopback test to be complete. "Port Management" message (type (Section 5.4.2.3).
32) is used. The result field SHOULD be set to success or failure.
The function type SHOULD be set to 0x09. The transaction ID SHOULD
be copied from the sequence number contained in the corresponding
request. The other parameters not explicitly defined here SHOULD be
set as specified in the request message above. The code field SHOULD
be set to a value in the range 0x500 to 0x5ff (to be reserved with
IANA) to indicate the status of the executed test. The valid values
defined are (can be extended in future):
0x500 : Specified access line does not exist o Access-Loop-Circuit-ID TLV (as defined in Section 5.2.3.3);
0x501 : Loopback test timed out o Access-Aggregation-Circuit-ID-Binary TLV (as defined in
Section 5.2.3.3);
0x502 : Reserved o Access-Aggregation-Circuit-ID-ASCII TLV (as defined in
Section 5.2.3.3);
0x503 : DSL line status showtime o OAM-Loopback-Test-Parameters TLV;
0x504 : DSL line status idle o Opaque-Data TLV;
0x505 : DSL line status silent o OAM-Loopback-Test-Response-String TLV.
0x506 : DSL line status training If not otherwise indicated, the TLVs listed above are defined in
Section 5.4.2.4.
0x507 : DSL line integrity error 5.4.2.2. Message Format
0x508 : DSLAM resource not available The Port Management message for DSL line testing has the same format
as for DSL line configuration (see Section 5.3.3.2), with the
following differences:
0x509 : Invalid test parameter o The Result field in the request SHOULD be set to AckAll (0x1), to
allow the NAS to receive the information contained in a successful
test response.
The Extension value can contain one or more TLVs including the TLV to o The Function field MUST be set to 9 (Remote Loopback). (The
identify the access line on which the test was performed, and details X-Function field continues to be 0.)
from executing the test. The access line identifier SHOULD be
identical to what was contained in the request. The relevant TLVs
are:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section o The appended TLVs in the extension value field include testing-
Section 5.4.1 related TLVs rather than subcriber service information.
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 5.4.2.3. Procedures
section Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in The ANCP Port Management message as described in Section 5.4.2.2 MAY
section Section 5.4.1 be used by the NAS to trigger the Access Node to run a loopback test
on the local loop. To identify the line to be tested, the NAS MUST
include one of Access-Loop-Circuit-ID TLV, Access-Aggregation-
Circuit-ID-Binary TLV, or Access-Aggregation-Circuit-ID-ASCII TLV in
the Port Management message, depending upon the deployment scenario.
The NAS MAY include the OAM-Loopback-Test-Parameters and/or Opaque-
Data TLVs (defined in Section 5.4.2.4) to configure the loopback test
for that line.
o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the The Access Node SHOULD generate a Port Management response when it
request reflected back by the DSLAM. deems the loopback test to be complete. (The exception is described
with reference to the Timeout field in the OAM-Loopback-Test-
Parameters TLV in Section 5.4.2.4.) The Result field MUST be set to
Success (0x3) or Failure (0x4) as applicable. The Code field SHOULD
be set to one of the following values if applicable.
Length : (up to 8 bytes) 1280 (0x500): Specified access line does not exist
Value : Two 32 bit integers as received in the request (opaque 1281 (0x501): Loopback test timed out
to the DSLAM).
o Type (OAM-Loopback-Test-Response-String = 0x09) 1282 (0x502): Reserved
Length : (up to 128 bytes) 1283 (0x503): DSL line status showtime
Value : Suitably formatted ASCII string containing useful 1284 (0x504): DSL line status idle
details about the test that the NAS will display for the
operator, exactly as received from the DSLAM (no manipulation/
interpretation by the NAS). This is an optional TLV, but it is
strongly recommended, that in case of ATM based local loop, the
DSLAM at the very least indicates via this TLV, the total
loopback cells generated and the total loopback cells
successfully received as part of executing the requested
loopback test.
5.4.5. Additional GSMP Extensions for future use cases 1285 (0x505): DSL line status silent
GSMP protocol defined in [RFC3292] allows for two messaging 1286 (0x506): DSL line status training
principles in case of Request/Response interaction:
o The same message type used for both request message and response 1287 (0x507): DSL line integrity error
message where result field and code field settings are used to
differentiate between request and response messages;
o Two different message types for request message and response 1288 (0x508): DSLAM resource not available
messages.
First message principle has been adopted for use cases defined in 1289 (0x509): Invalid test parameter
sections Section 5.4.2 to Section 5.4.4, the purpose of this section
is to specify the second type of approach in order to allow the use
of this message principle for the development of future use cases.
In the new message paradigm different message types are used as ANCP All other fields including the appended TLVs MUST be copied from the
Request Message and ANCP Response Message: the format of a generic request, except that the OAM-Loopback-Test-Parameters TLV MUST NOT
ANCP message starts with the common GSMP header as in the case of the appear in the response and the OAM-Loopback-Test-Response-String TLV
existing ANCP implementation, but the Result field is set to Ignore SHOULD appear in the response.
in order to instruct the receipt to ignore this field and follow the
procedures specified for the received message type. The Transaction
Identifier field is used to distinguish between request messages and
to associate a response message to a request. Applications that
require such response correlation MUST set the Transaction Identifier
to a value in the range (1, 2^24 - 1). When used in this manner, the
Transaction Identifier sequencing MUST be maintained independently
for each ANCP adjacency and per message type. Furthermore, it SHOULD
be incremented linearly for each new message of the given type,
cycling back to 1 after running the full range. Message types not
requiring response message correlation SHOULD set the Transaction Id
field to 0x0. In the event of an ANCP transport protocol failure,
all pending ANCP messages destined to the disconnected recipient can
be discarded until the transport is re- established following which
the Transaction Identifier is re- initialized.
The value of the Transaction Identifier in a Response message MUST be Section 5.4.2.4 contains additional procedures relating to specific
set to that of the respective Request message. This allows the TLVs.
Requester to correlate the Response to the original Request. The
Transaction Identifier is not used in ANCP adjacency messages. Also,
other ANCP applications not requiring it SHOULD set the Transaction
Identifier to 0x0 in their messages.
All TLVs within the ANCP message have to be 32 bit aligned, and when 5.4.2.4. TLVs For the DSL Line Test Capability
necessary padded with 0s to the 32 bit boundary. The padding is not
reflected in the message length field.
5.4.5.1. General well known TLVs The following TLVs have been defined for use with the DSL line
testing capability.
This section contains the definitions of three general well known 5.4.2.4.1. OAM-Loopback-Test-Parameters TLV
TLVs. These TLVs are intended to be re-usable across different
messages.
5.4.5.1.1. Target TLV Name: OAM-Loopback-Test-Parameters
The Target TLV (0x1000 - 0x01020) is intended to be a general well Type: 0x0007
known TLV allowing the representation of different types of objects.
Its use is not restricted to any specific Message Type.
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 Description: Parameters related to a loopback test. This is an
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional TLV. If this TLV is not present in the request message,
| TLV Type = Target | Target-TLV Length | the DSLAM SHOULD use locally determined default values for the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ test parameters.
| |
~ Target Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target TLV: Length: 2 bytes
TLV (0x1000 - 0x1020) indicating the type of target being Value: two 1 byte fields described below (listed in order of most to
addressed. Target TVL 0x1000 indicates a single Access- least significant).
Port.
Target TLV Length: Byte 1: Count. Number of loopback cells/messages that should
be generated on the local loop as part of the loopback test.
The NAS SHOULD restrict the "count" to be greater than 0 and
less than or equal to 32. The DSLAM SHOULD discard a request
for a loopback test, if the received test parameters contain an
out of range value for the "count" field. The AN MAY include a
Code value of 0x509 "Invalid test parameter" in the resulting
failure response to the NAS.
Length in bytes of Target Info. Excludes TLV header Byte 2: Timeout. Upper bound on the time in seconds that the
NAS will wait for a response from the DSLAM. If the total time
taken by the DSLAM to complete a test with requested
parameters, exceeds the specified "timeout" value, it MAY
choose to omit the generation of a response to the NAS. The
DSLAM SHOULD use a locally determined value for Timeout, if the
received value of the Timeout parameter is 0.
Target Info: The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 14
Target information as defined for each the given target. 0 1 2 3
The field can consist of sub-TLVs. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: The OAM-Loopback-Test-Parameters TLV
In its simplest form, when targeting a single access line the Target- 5.4.2.4.2. Opaque-Data TLV
TLV will be set to a value of (0x1000), and carry in its payload one
or more sub-TLVs identifying the target. The following example
illustrates the message format for a single port identified by an
Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a
Port-UP message:
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 Name: Opaque-Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5.1.2. Command TLV Type: 0x0008
The Command TLV (0x11) is intended to be a general well known TLV Description: This is an optional TLV. If it is present in the
allowing the encapsulation of one or more command directives in a TLV request message, the DSLAM SHOULD reflect it back in the response
oriented message. The semantics of the command are allowed to be unmodified.
specified for each message type, ie different message types that
choose to carry the Command TLV are expected to define the meaning of
the content of the payload, which could be re-used from those already
defined elsewhere if appropriate.
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 Length: 8 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Command | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Command Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional sub-TLV Type | Additional sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional sub-TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Command TLV: Value: Two 32 bit unsigned integers inserted by the NAS (not to be
interpreted by the DSLAM, but just reflected back in the
response).
TLV (0x11) indicating the contents to be one or more 5.4.2.4.3. OAM-Loopback-Test-Response-String TLV
command directives.
Command TLV Length: Name: OAM-Loopback-Test-Response-String
Combined length in bytes of the data in Command Info and Type: 0x0009
sub-TLV. Excludes the Command TLV header
Commad-Info: Description: Suitably formatted ASCII string containing useful
details about the test that the NAS will display for the operator,
exactly as received from the DSLAM (no manipulation/interpretation
by the NAS). This is an optional TLV, but it is strongly
RECOMMENDED that in case of ATM based local loop, the DSLAM at the
very least indicates, via this TLV, the total loopback cells
generated and the total loopback cells successfully received as
part of executing the requested loopback test.
Command information as defined for each message type. The Length: up to 128 bytes
field can consist of sub-TLVs.
Additional sub-TLV: Value: ASCII string.
Additional sub-TLVs can be present in a command TLV. Any 6. Additional ANCP Messages and TLVs
such sub-TLVs must directly follow each command.
Additional sub-TLV Length: This section defines two messages and a number of TLVs that may be
useful in multiple capabilities. Typically the content is under-
specified, with the intention that particular capabilities spell out
the remaining details.
Number of actual bytes contained in the value portion of 6.1. Additional Messages and General Messaging Principles
each additional sub-TLV
5.4.5.1.3. Status-info TLV 6.1.1. General Principles for the Design of ANCP Messages
The Status-info-TLV is intended to be a general well known TLV used The GSMPv3 protocol [RFC3292] allows for two messaging constructs to
to convey the status code regarding commands and/or requests. The support request/response interaction:
format of the Status-info-TLV (0x0106) is shown below.
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 a. The same message type is used for both the request message and
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the response message. The Result and Code field settings are
| TLV Type = Status-info | Status TLV Length | used to differentiate between request and response messages.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (aligned to 4 bytes length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Status-info TLV: b. The request and response messages use two different message
types.
TLV (0x106) conveying the status or error response of a The first approach is illustrated by the protocol specifications in
command Section 5. The purpose of this section is to provide more details
about the second approach in order to allow the use of this messaging
construct for the development of additional ANCP extensions.
Status TLV Length: As Section 4.4 indicated, all ANCP messages other than adjacency
messages share a common header format. When the response message
type is different from that of the request, the specification of the
request message will typically indicate that the Result field is set
to Ignore (0x0) and provide procedures indicating explicitly when the
receiver should generate a response and what message type it should
use.
Specifies the length in bytes of the Status Info TLV The Transaction ID field is used to distinguish between request
payload. Excludes the TLV header messages and to associate a response message to a request.
Specifications of ANCP messages for applications not requiring
response correlation should indicate that the Transaction ID must be
set to zero in requests. Applications that require response
correlation should refer to the Transaction ID behaviour described in
Section 4.4.1.
Reserved: The specification for a response message should indicate in all cases
that value of the Transaction Identifier must be set to that of the
corresponding request message. This allows the requester to
establish whether or not correlation is needed (by setting a non-zero
or zero value for the Transaction ID).
This field MUST be set to all zeroes by the sender and 6.1.2. Provisioning Message
ignored by the receiver.
Msg Type: The Provisioning message is sent by the NAS to the AN to provision
information of global scope on the AN. The Provisioning message has
the format shown in Figure 15.
The message type value of the message the Status-info TLV 0 1 2 3
is reporting on 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 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Message Length: Figure 15: Format of the Provisioning Message
It contains the length of an optional error message or 0 if This document specifies the following fields. The remaining fields
none. in the ANCP general message header MUST be set as specified in
Section 4.4.1. The TLVs are specified elsewhere on a per-capability
basis. The Provisioning message MAY be used to carry data relating
to more than one capability at once, assuming that the capabilities
concerned can co-exist and have all been negotiated during adjacency
establishment.
Error message: Message Type: MUST be set to 93.
It contains a human-readable description of the error being Result: MUST be set to 0x0 (Ignore).
reported by the Status-info field.
TLVs: Code: MUST be set to zero.
This field is of indeterminate length, and contains zero or Transaction ID: MUST be populated with a non-zero value chosen in
more of the TLVs associated with the Status-info TLV. The the manner described in Section 4.4.1.
following TLVs are RECOMMENDED to be provided if the
indicated Code values are given in the header of the
message containing the Status-info TLV:
Code value 4 or 5: the Target or other TLV identifying the If the AN can process the message successfully and accept all the
unknown or unavailable port. provisioning directives contained in it, the AN MUST NOT send any
response.
Code value 84: the TLV that is unsupported or contains the If not otherwise specified, if the AN fails to process the message
unsupported value. successfully it MUST send a Generic Response message (Section 6.1.3)
indicating failure and providing appropriate diagnostic information.
5.4.5.2. Generic Response Message 6.1.3. Generic Response Message
This section defines the Generic Response message. The Generic This section defines the Generic Response message. The Generic
Response message may be specified as the appropriate response to a Response message may be specified as the appropriate response to a
message defined in an extension to ANCP, instead of a more specific message defined in an extension to ANCP, instead of a more specific
response message. As a general guideline, specification of the response message. As a general guideline, specification of the
Generic Response message as a response is appropriate where no data Generic Response message as a response is appropriate where no data
needs to be returned to the peer other than a result (success or needs to be returned to the peer other than a result (success or
failure), plus, in the case of a failure, a code indicating the failure), plus, in the case of a failure, a code indicating the
reason for failure and a limited amount of diagnostic data. reason for failure and a limited amount of diagnostic data.
Depending on the particular use case, the Generic Response message Depending on the particular use case, the Generic Response message
MAY be sent by either the NAS or the AN. MAY be sent by either the NAS or the AN.
The AN or NAS MAY send a Generic Response message indicating a The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this the adjacency as a consequence of that failure condition. In this
case, the sender MUST set the Transaction Identifier field in the case, the sender MUST set the Transaction ID field in the header and
header and the Message Type field within the Status-info TLV to the Message Type field within the Status-Info TLV to zeroes. The
zeroes. The receiver MAY record the information contained in the receiver MAY record the information contained in the Status-info TLV
Status-info TLV for management use. for management use.
The format of the Generic Response message is shown in Figure 17 The format of the Generic Response message is shown in Figure 16
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 |Result | Code | | ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Status-Info TLV |
~ (Section 6.2.3) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
Figure 16: Structure of the Generic Response Message
This document specifies the following fields. The remaining fields
in the ANCP general message header MUST be set as specified in
Section 4.4.1.
Message Type: MUST be set to 91.
Result: MUST be set to 0x3 (Success) or 0x4 (Failure).
Code: MUST be set to zero for success or an appropriate non-zero
value for failure.
Transaction ID: MUST be copied from the message to which this
message is a response.
Status-Info TLV: MAY be present in a success response, to provide a
warning as defined for a specific request message type. MUST be
present in a failure response. See Section 6.2.3 for a detailed
description of the Status- Info TLV. The actual contents will
depend on the request message type this message is responding to.
6.2. TLVs For General Use
This section contains the definitions of some TLVs that are intended
to be re-usable across different message types and capabilities.
6.2.1. Target TLV
Name: Target
Type: 0x1000 to 0x1020 depending on the specific content. Only
0x1000 has been assigned in this specification (see below).
Description: The Target TLV (0x1000 - 0x1020) is intended to be a
general means to represent different types of objects.
Length: Variable, depending on the specific object type.
Value: Target information as defined for each object type. The
field can consist of sub-TLVs.
TLV Type 0x1000 is assigned to a variant of the Target TLV
representing a single access line and encapsulating one or more sub-
TLVs identifying the target. Figure 17 illustrates the message
format for a single port identified by an Access-Loop-Circuit-ID TLV
(0x0001) that could be derived from a Port-UP message:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=0x106 | Status-TLV-Length | | TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg type | Error Message Length | | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length &gt; 0 | | |
+---------------------------------------------------------------+ ~ Access Loop Circuit ID ~
| sub-TLVs... | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Structure of the Generic Response Message Figure 17: Example of Target TLV For Single Access Line
Message Type: 6.2.2. Command TLV
The message type value for the Generic Response message is 0x91. Name: Command
Result: Type: 0x0011
The value of the Result field for the Generic Response message Description: The Command TLV (0x0011) is intended to be a general
MUST be either Success (0x03) or Failure (0x04). means of encapsulating one or more command directives in a TLV
oriented message. The semantics of the command can be specified
for each message type using it. I.e., the specification of each
message type that can carry the Command TLV is expected to define
the meaning of the content of the payload, although re-use of
specifications is, of course, permissible when appropriate.
Code: Length: Variable, depending on the specific contents.
The Code field MUST have value zero if Result is set to Success Value: Command information as defined for each message type. The
(0x03). It MUST have an appropriate non-zero value if Result is field can include sub-TLVs. The contents of this TLV MUST be
set to Failure (0x04). As discussed in section 5, extensions to specified as one "command" or alternatively a sequence of one or
ANCP MAY define new Code values for use in failure responses for more "commands", each beginning with a one-byte Command Code and
specific request message types. possibly including other data following the Command Code. An IANA
registry has been established for Command Code values. This
document reserves the Command Code value 0 as an initial entry in
the registry.
Partition ID: 6.2.3. Status-Info TLV
As specified in section Section 5. Name: Status-Info
Transaction Identifier: Type: 0x0106
The Transaction Identifier MUST be copied from the request to Description: The Status-Info-TLV is intended to be a general
which the Generic Response message is responding. container for warning or error diagnostics relating to commands
and/or requests. It is a supplement to the Code field in the ANCP
general header. The specifications for individual message types
may indicate the use of this TLV as part of responses,
particularly for failures. As mentioned above, the Generic
Response message will usually include an instance of the Status-
Info TLV.
I, Sub-message Number, Length: Length: Variable, depending on the specific contents.
As specified in Section 5. Value: The following fixed fields. In addition, sub-TLVs may be
appended to provide further diagnostic information.
Status-info TLV: Reserved: see Section 4.4.2.1 for handling of reserved fields.
MAY be present in a success response, to provide a warning as Msg Type: Message Type of the request for which this TLV is
defined for a specific request message type. MUST be present in a providing diagnostics.
failure response. The Message Type field value is copied from the
header of the request message. The Error Message field contains
human-readable diagnostic text. The description of the response
for a particular request message type MAY specify further sub-TLVs
to be included in Status-info, either generally or for specific
failure Code values.
5.5. ATM-specific considerations Error Message Length: Number of bytes in the error message,
excluding padding. This MAY be zero if no error message is
provided.
The topology discovery and line configuration involve the DSL line Error Message: Human-readable string providing information about
attributes. For ATM based access networks, the DSL line on the DSLAM the warning or error condition. Padded with zeroes as
is identified by the port and PVP/PVC corresponding to the necessary to extend to a four-byte word boundary.
subscriber. The DSLAMs are connected to the NAS via an ATM access
aggregation network. Since, the DSLAM (access-node) is not directly
connected to the NAS, the NAS needs a mechanism to learn the DSL line
identifier (more generally referred to as "Access Loop Circuit-ID")
corresponding to a subscriber. The "Access loop circuit-ID" has no
local significance on the NAS. The ANCP messages for topology
discovery and line configuration carry opaque "Access loop
Circuit-ID" which has only local significance on the DSLAMs.
The access loop circuit identifier can be carried as an ASCII string The following TLVs are RECOMMENDED to be appended if the indicated
in the ANCP messages. This allows ANCP to be decoupled from the Code values are given in the header of the message containing the
specifics of the underlying access technology being controlled. On Status-info TLV:
the other hand, this requires a NAS mechanism by which such
identifier can be correlated to the context of an "aggregation
network" facing IP interface (corresponding to the subscriber) on the
NAS. This would typically require local configuration of such IP
interfaces, or of the underlying ATM interfaces.
5.6. Ethernet-specific considerations * Code value 4 or 5: the Target or other TLV identifying the
unknown or unavailable port.
One possible way of approaching the use of Ethernet technology in the * Code value 84: the TLV that is unsupported or contains the
access aggregation network is to recreate the equivalent of Virtual unsupported value.
Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN
tags. As an example, one could use an "outer" VLAN to create a form
of "virtual path" between a given DSLAM and a given NAS. And then
use "inner" VLAN tags to create a form of "virtual circuit" on a per
DSL line basis. In this case, VLAN tags conveyed in topology
discovery and line configuration messages will allow to uniquely
identify the DSL line in a straightforward manner, assuming the VLAN
tags are not translated in some way by the aggregation network, and
are unique across physical ports.
However, some carriers do not wish to use this "connection oriented" Figure 18 illustrates the Status-Info TLV.
approach. Therefore, an alternative model is to bridge sessions from
multiple subscribers behind a DSLAM to a single VLAN in the
aggregation network. This is the N:1 model. In this model, or in
the case where user traffic is sent untagged, the access node needs
to insert the exact identity of the DSL line in the topology
discovery and line configuration messages, and then hve a mechanism
by which this can be correlated to the context of an "aggregation
network" facing IP interface (for the subscriber) on the NAS. This
can either be based on local configuration on the NAS, or on the fact
that such DSLAM (access node) typically inserts the "Access Loop
Circuit ID" in subscriber signaling messages relayed to the NAS (i.e.
DHCP or PPPoE discovery messages).
Section Section 5.4.1 defines "Access Loop Circuit ID". 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4 byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. IANA Considerations Figure 18: The Status-Info TLV
This document defines the following additions to the GSMPv3 Message 7. IANA Considerations
Type Name Space registry:
+--------------+--------+---------------+ RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this
| Message | Number | Source | specification.
+--------------+--------+---------------+
| Provisioning | 93 | This document |
+--------------+--------+---------------+
This document defines the following modification to the General 7.1. Summary
Switch Management Protocol version 3 (GSMPv3) Result Type Name Space
registry:
+--------------+------------------------+---------------+ This section requests the following IANA actions:
| Result Value | Result Type Name | Reference |
+--------------+------------------------+---------------+
| 0 | Ignore (from Reserved) | This document |
+--------------+------------------------+---------------+
This document defines the following addition to the GSMPv3 Message o addition of message types to the GSMPv3 Message Type Name Space
Function Name Space registry [editor's note GMSPv3 did not define a registry;
Name Space for Function even if RFC3292 defines values for function
field]:
+----------------+-----------------+---------------+ o addition of a result type to the GSMPv3 Result Type Name Space
| Function Value | Function Name | Reference | registry; [Editor's Note: may need an ANCP registry instead.
+----------------+-----------------+---------------+ Coordination between the two protocols is unnecessary because of
| 0x09 | Remote loopback | This document | ANCP's reorganization of the Result field.]
+----------------+-----------------+---------------+
The GSMPv3 Failure Response Message Name Space is extended from the o extension of limits [Editor's Note: assuming we are allowed to do
GSMPv3 limit of 255 to a new upper limit of 4095 and this document this!] and addition of failure codes to the GSMPv3 Failure
adds the following values to the GSMPv3 Failure Response Message Name Response Message Name Space registry;
Space registry:
+-------------------+-----------------------------------+-----------+ o establishment of the following new ANCP registries:
| Failure Response | Failure Response Message Name | Reference |
| Message Value | | |
+-------------------+-----------------------------------+-----------+
| 81d | Request message type not | This |
| | implemented (0x51) | document |
| 82d | Transaction identifier out of | This |
| | sequence (0x52) | document |
| 83d | Malformed message (0x53) | This |
| | | document |
| 84d | TLV or value not supported by | This |
| | negotiated capability set (0x54) | document |
| 85d | Invalid value in TLV (0x55) | This |
| | | document |
| From 256d to 499d | Reserved for IETF use (0x0100 - | This |
| | 0x1F3) | document |
| 1280d | Specified access line does not | This |
| | exist (0x500) | document |
| 1281d | Loopback test timed out (0x501) | This |
| | | document |
| 1282d | Reserved (0x502) | This |
| | | document |
| 1283 | DSL line status showtime (0x503) | This |
| | | document |
| 1284 | DSL line status idle (0x504) | This |
| | | document |
| 1285 | DSL line status silent (0x505) | This |
| | | document |
| 1286 | DSL line status training (0x506) | This |
| | | document |
| 1287 | DSL line integrity error (0x507) | This |
| | | document |
| 1288 | DSLAM resource not available | This |
| | (0x508) | document |
| 1289 | Invalid test parameter (0x509) | This |
| | | document |
| From 509d to | Reserved for IETF use (0x1FD - | This |
| 4095d | 0XFFF) | document |
+-------------------+-----------------------------------+-----------+
This document reserves the values 256 to 499 and 509 to 4095 within ANCP Function Codes; [Editor's Note: GSMPv3 has no function
the GSMPv3 Failure Response Message Name Space registry for use by code registry, so this one might as well belong to ANCP.
extensions to the Access Node Control Protocol (ANCP). Coordination between the two protocols is unnecessary because
of ANCP's reorganization of the Function field.]
This document defines a new ANCP Version Space registry. The initial ANCP Technology Types;
entry is as follows:
+--------------------+-------------------+---------------+ ANCP Command Codes;
| ANCP Version Value | ANCP Version Name | Reference |
+--------------------+-------------------+---------------+
| 3 | ANCP Version | This document |
+--------------------+-------------------+---------------+
This document defines a new ANCP Sub-Version Space registry. The ANCP TLV Types;
initial entry is as follows:
+------------------------+-----------------------+---------------+ ANCP Capabilities.
| ANCP Sub-Version Value | ANCP Sub-Version Name | Reference |
+------------------------+-----------------------+---------------+
| 1 [*] | ANCP Sub-Version | This document |
+------------------------+-----------------------+---------------+
[*] Editor's note: sub-version needs to be changed from 1 to 2 upon 7.2. IANA Actions
publication
This document defines a new ANCP Tech Type Name Space registry. The IANA is requested to add a new message category to the GSMPv3 Message
initial entries are as follows: Type Name Space registry: "Access Network Control Protocol (ANCP)
Messages". IANA is requested to add the following entries under that
category:
+-----------------+----------------------------+---------------+ +------------------+----------------+--------+-----------+
| Tech Type Value | Tech Type Name | Reference | | Message Name | Message Number | Status | Reference |
+-----------------+----------------------------+---------------+ +------------------+----------------+--------+-----------+
| 0x00 | Extension block not in use | This document | | Generic Response | 91 | | RFCXXXX |
| 0x01 | PON | This document | | Provisioning | 93 | | RFCXXXX |
| 0x05 | DSL | This document | +------------------+----------------+--------+-----------+
| 0x06 - 0xFE | Reserved | This document |
| 0xFF | Base Specification Use | This document |
+-----------------+----------------------------+---------------+
This document defines a new ANCP Command Code registry. The initial IANA is requested to implement the following modification to the
entries are as follows: General Switch Management Protocol version 3 (GSMPv3) Result Type
Name Space registry:
+-----------------------------+--------------------+---------------+ +--------------+-----------------------+-----------+
| Command Code Directive Name | Command Code Value | Reference | | Result Value | Result Type Name | Reference |
+-----------------------------+--------------------+---------------+ +--------------+-----------------------+-----------+
| Reserved | 0x00 | This document | | 0 | Ignore (was Reserved) | RFCXXXX |
+-----------------------------+--------------------+---------------+ +--------------+-----------------------+-----------+
This document defines a new ANCP TLV Type registry. The initial IANA is requested to implement the following modifications to the
entries are as follows: GSMPv3 Failure Response Message Name Space:
+--------------------------------------+--------------+-------------+ o Add the following note to the registry:
| TLV Name | Type Code | Reference |
+--------------------------------------+--------------+-------------+
| Access-Loop-Circuit-ID | 0x01 | This |
| | | document |
| Access-Loop-Remote-Id | 0x02 | This |
| | | document |
| Access-Aggregation-Circuit-ID-ASCII | 0x03 | This |
| | | document |
| DSL Line Attributes | 0x04 | This |
| | | document |
| Service-Profile-Name | 0x05 | This |
| | | document |
| Access-Aggregation-Circuit-ID-Binary | 0x06 | This |
| | | document |
| OAM-Loopback-Test-Parameters | 0x07 | This |
| | | document |
| Opaque-Data | 0x08 | This |
| | | document |
| OAM-Loopback-Test-Response-String | 0x09 | This |
| | | document |
| Reserved | 0x0a-0x0f | This |
| | | document |
| Target | 0x1000 - | This |
| | 0X1020 | document |
| Command | 0x11 | This |
| | | document |
| Status-info | 0x0106 | This |
| | | document |
+--------------------------------------+--------------+-------------+
This document defines a new ANCP Capability registry. The initial This registry is shared with the Access Node Control Protocol
entries are as follows: (ANCP) [RFCXXXX]. GSMPv3 [RFC3292] allows values up to a
maximum of 255. ANCP extends this maximum to 4095. Hence
values above 255 are applicable to ANCP only.
+----------------------------+----------------------+---------------+ o Extend the table of registration procedures as indicated.
| Capability Type Name | Capability Type Code | Reference |
+----------------------------+----------------------+---------------+
| Dynamic-Topology-Discovery | 0x01 | This document |
| Line-Configuration | 0x02 | This document |
| Transactional-Multicast | 0x03 | This document |
| OAM | 0x04 | This document |
+----------------------------+----------------------+---------------+
This document defines a new ANCP sub-TLV Type registry. The initial o Add entries to the failure response message name table as
entries are as follows: indicated.
+--------------------------------------------+--------+-------------+ o Replace the ranges of unassigned codes at the end of the failure
| sub-TLV Name | Type | Reference | response message name table as indicated.
| | Code | |
+--------------------------------------------+--------+-------------+
| Actual-Net-Data-Upstream | 0x81 | This |
| | | document |
| Actual-Net-Data-Rate-Downstream | 0x82 | This |
| | | document |
| Minimum-Net-Data-Rate-Upstream | 0x83 | This |
| | | document |
| Minimum-Net-Data-Rate-Downstream | 0x84 | This |
| | | document |
| Attainable-Net-Data-Rate-Upstream | 0x85 | This |
| | | document |
| Attainable-Net-Data-Rate-Downstream | 0x86 | This |
| | | document |
| Maximum-Net-Data-Rate-Upstream | 0x87 | This |
| | | document |
| Maximum-Net-Data-Rate-Downstream | 0x88 | This |
| | | document |
| Minimum-Net-Low-Power-Data-Rate-Upstream | 0x89 | This |
| | | document |
| Minimum-Net-Low-Power-Data-Rate-Downstream | 0x8A | This |
| | | document |
| Maximum-Interleaving-Delay-Upstream | 0x8B | This |
| | | document |
| Actual-Interleaving-Delay-Upstream | 0x8C | This |
| | | document |
| Maximum-Interleaving-Delay-Downstream | 0x8D | This |
| | | document |
| Actual-Interleaving-Delay-Downstream | 0x8E | This |
| | | document |
| DSL line state | 0x8F | This |
| | | document |
| Access Loop Encapsulation | 0x90 | This |
| | | document |
| DSL-Type | 0x91 | This |
| | | document |
+--------------------------------------------+--------+-------------+
7. Security Considerations +----------+------------------------+---------------+
| Range | Registration Procedure | Notes |
+----------+------------------------+---------------+
| 256-4095 | IETF Consensus | ANCP use only |
+----------+------------------------+---------------+
+-------+-----------------------------------------------+-----------+
| Value | Failure Response Message Name | Reference |
+-------+-----------------------------------------------+-----------+
| 81 | Request message type not implemented (0x51) | RFCXXXX |
| 82 | Transaction identifier out of sequence (0x52) | RFCXXXX |
| 83 | Malformed message (0x53) | RFCXXXX |
| 84 | TLV or value not supported by negotiated | RFCXXXX |
| | capability set (0x54) | |
| 85 | Invalid value in TLV (0x55) | RFCXXXX |
| 1280 | Specified access line does not exist (0x500) | RFCXXXX |
| 1281 | Loopback test timed out (0x501) | RFCXXXX |
| 1282 | Reserved (0x502) | RFCXXXX |
| 1283 | DSL line status showtime (0x503) | RFCXXXX |
| 1284 | DSL line status idle (0x504) | RFCXXXX |
| 1285 | DSL line status silent (0x505) | RFCXXXX |
| 1286 | DSL line status training (0x506) | RFCXXXX |
| 1287 | DSL line integrity error (0x507) | RFCXXXX |
| 1288 | DSLAM resource not available (0x508) | RFCXXXX |
| 1289 | Invalid test parameter (0x509) | RFCXXXX |
+-------+-----------------------------------------------+-----------+
+-----------+-------------------------------+-----------+
| Value | Failure Response Message Name | Reference |
+-----------+-------------------------------+-----------+
| 8-9 | Unassigned | |
| 47-59 | Unassigned | |
| 86-127 | Unassigned | |
| 160-255 | Unassigned | |
| 256-1279 | Unassigned (ANCP use only) | |
| 1290-4095 | Unassigned (ANCP use only) | |
+-----------+-------------------------------+-----------+
IANA is requested to create a new ANCP Port Management Function Name
registry, with the following initial entries. Additions to this
registry will be by IETF Consensus. Values may range from 0 to 255.
[Editor's Note: what about X-Function? Probably has to be a sub-
registry of Function.]
+----------------+-----------------------------------+-----------+
| Function Value | Function Name | Reference |
+----------------+-----------------------------------+-----------+
| 0 | Reserved | RFCXXXX |
| 1-7 | Unassigned | |
| 8 | Configure Connection Service Data | RFCXXXX |
| 9 | Remote Loopback | RFCXXXX |
| 10-255 | Unassigned | |
+----------------+-----------------------------------+-----------+
IANA is requested to create a new ANCP Version registry, with
additions by IETF consensus. The initial entries are as follows:
[Editor's Note: assumes that proposal to combine version and sub-
version into a single registry is accepted.]
+---------+-------------+--------------+----------------------------+
| Version | Sub-Version | Name | Reference |
+---------+-------------+--------------+----------------------------+
| 3 | 1 | Pre-standard | [Could identify a draft |
| | | | version] |
| 3 | 2 | ANCPv1 | RFCXXXX |
+---------+-------------+--------------+----------------------------+
IANA is requested to create a new ANCP Technology Type registry, with
additions by IETF Consensus. Values may range from 0 to 255. The
initial entries are as follows:
[Editor's Note: probably need text in the main body of the document
explaining 0x00 and 0xFF. Latter probably has to be Reserved and
remaining values simply Unassigned.]
+-----------------+----------------------------+-----------+
| Tech Type Value | Tech Type Name | Reference |
+-----------------+----------------------------+-----------+
| 0 | Extension block not in use | RFCXXXX |
| 1 | PON | RFCXXXX |
| 2-4 | Unassigned | |
| 5 | DSL | RFCXXXX |
| 6-254 | Unassigned | |
| 255 | Reserved | RFCXXXX |
+-----------------+----------------------------+-----------+
IANA is requested to create a new ANCP Command Code registry, with
additions by IETF Consensus. The initial entry is as follows:
+--------------------+-----------------------------+-----------+
| Command Code Value | Command Code Directive Name | Reference |
+--------------------+-----------------------------+-----------+
| 0 | Reserved | RFCXXXX |
+--------------------+-----------------------------+-----------+
IANA is requested to create a new ANCP TLV Type registry, with
additions by IETF Consensus. Values may range from 0x0000 to 0xFFFF.
New assignments should be in the range of values from 0x0100 upwards.
The initial entries are as follows:
+--------------+----------------------------------------+-----------+
| Type Code | TLV Name | Reference |
+--------------+----------------------------------------+-----------+
| 0x0000 | Reserved | RFCXXXX |
| 0x0001 | Access-Loop-Circuit-ID | RFCXXXX |
| 0x0002 | Access-Loop-Remote-Id | RFCXXXX |
| 0x0003 | Access-Aggregation-Circuit-ID-ASCII | RFCXXXX |
| 0x0004 | DSL Line Attributes | RFCXXXX |
| 0x0005 | Service-Profile-Name | RFCXXXX |
| 0x0006 | Access-Aggregation-Circuit-ID-Binary | RFCXXXX |
| 0x0007 | OAM-Loopback-Test-Parameters | RFCXXXX |
| 0x0008 | Opaque-Data | RFCXXXX |
| 0x0009 | OAM-Loopback-Test-Response-String | RFCXXXX |
| 0x000a-0x001 | Unassigned | |
| 0 | | |
| 0x0011 | Command | RFCXXXX |
| 0x0012-0x008 | Unassigned | |
| 0 | | |
| 0x0081 | Actual-Net-Data-Upstream | RFCXXXX |
| 0x0082 | Actual-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0083 | Minimum-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0084 | Minimum-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0085 | Attainable-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0086 | Attainable-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0087 | Maximum-Net-Data-Rate-Upstream | RFCXXXX |
| 0x0088 | Maximum-Net-Data-Rate-Downstream | RFCXXXX |
| 0x0089 | Minimum-Net-Low-Power-Data-Rate-Upstre | RFCXXXX |
| | am | |
| 0x008A | Minimum-Net-Low-Power-Data-Rate-Downst | RFCXXXX |
| | ream | |
| 0x008B | Maximum-Interleaving-Delay-Upstream | RFCXXXX |
| 0x008C | Actual-Interleaving-Delay-Upstream | RFCXXXX |
| 0x008D | Maximum-Interleaving-Delay-Downstream | RFCXXXX |
| 0x008E | Actual-Interleaving-Delay-Downstream | RFCXXXX |
| 0x008F | DSL line state | RFCXXXX |
| 0x0090 | Access Loop Encapsulation | RFCXXXX |
| 0x0091 | DSL-Type | RFCXXXX |
| 0x092-0x0105 | Unassigned | |
| 0x0106 | Status-info | RFCXXXX |
| 0x0107-0x0FF | Unassigned | |
| F | | |
| 0x1000 | Target (single access line variant) | RFCXXXX |
| 0x1001 - | Reserved for Target variants | RFCXXXX |
| 0x1020 | | |
| 0x1021-0xFFF | Unassigned | |
| F | | |
+--------------+----------------------------------------+-----------+
IANA is requested to create a new ANCP Capability registry, with
additions by IETF Consensus. Values may range from 0 to 255. The
initial entries are as follows:
+-------+------------------------+-----------+
| Value | Capability Type Name | Reference |
+-------+------------------------+-----------+
| 0 | Reserved | RFCXXXX |
| 1 | DSL Topology Discovery | RFCXXXX |
| 2 | DSL Line Configuration | RFCXXXX |
| 3 | Reserved | RFCXXXX |
| 4 | DSL Line Testing | RFCXXXX |
| 5-255 | Unassigned | |
+-------+------------------------+-----------+
8. Security Considerations
Security of the ANCP protocol is discussed in [RFC5713] Security of the ANCP protocol is discussed in [RFC5713]
8. Acknowledgements 9. Acknowledgements
The authors would like to thank everyone that has provided comments The authors would like to thank everyone that has provided comments
or inputs to this document. In particular, the authors acknowledge or inputs to this document. Swami Subramanian was an early member of
the authors' team. The ANCP Working Group is grateful to Roberta
Maglione, who served as design team member and primary editor of this
document for two years before stepping down. The authors acknowledge
the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel
Platnic and Tom Taylor. Platnic.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292, "General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002. June 2002.
[RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch [RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch
Management Protocol (GSMP) Packet Encapsulations for Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", RFC 3293, June 2002. Transmission Control Protocol (TCP)", RFC 3293, June 2002.
9.2. Informative References [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ANCP-FRAMEWORK] 10.2. Informative References
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-13.txt, work in progress,
February 2010.
[G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair
bonding", 2005. bonding", 2005.
[G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair [G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding,", 2005. bonding,", 2005.
[RFC5713] Moustafa , H., Tschofenig, H., and S. De Cnodder, [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
"Security Threats and Security Requirements for the Access Threats and Security Requirements for the Access Node
Node Control Protocol (ANCP)", January 2010. Control Protocol (ANCP)", RFC 5713, January 2010.
[TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010.
[TR_058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service
Architecture & Framework Requirements", September 2003. Architecture & Framework Requirements", September 2003.
[TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution - [TR_059] Anschutz, T., "DSL Forum TR-059, DSL Evolution -
Architecture Requirements for the Support of QoS-Enabled Architecture Requirements for the Support of QoS-Enabled
IP Services", September 2003. IP Services", September 2003.
[TR-092] "DSL Forum TR-092, Broadband Remote access server [TR_092] "DSL Forum TR-092, Broadband Remote access server
requirements document", 2005. requirements document", 2005.
[TR-101] Cohen et al, "Architecture & Transport: "Migration to [TR_101] Cohen et al, "Architecture & Transport: "Migration to
Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005. Ethernet Based DSL Aggregation", DSL Forum TR-101", 2005.
Appendix A. Changes from Version -09 to Version -10
The changes to this document are editorial, although clarifications
may have inadvertently introduced some small technical differences.
The biggest change was a rearrangement of text to provide a clear
separation between generally applicable protocol aspects and the
three DSL capabilities documented here. The following table provides
a mapping between section numbers in the -09 version and section
numbers in the -10 version, with comments where text was modified
significantly.
+--------------+--------------+-------------------------------------+
| -09 Section | -10 Section | Comments |
+--------------+--------------+-------------------------------------+
| Abstract | Abstract | Rewritten to better reflect |
| | | contents. |
| - | - | - |
| 1 | 1 | |
| - | - | - |
| 2 | 5.2 | First two paragraphs moved. |
| | | Remainder smoothed a bit. Added |
| | | document outline. |
| - | - | - |
| 2.1 | 2.1 | Added definitions for TLV, ANCP |
| | | capability, ANCP session |
| | | (adjacency). |
| - | - | - |
| 3, 3.1, 3.2 | Same | |
| - | - | - |
| 4.1 | 5.1 | First paragraph dropped. |
| - | - | - |
| 4.2.1, 4.2.2 | 5.2.1, 5.2.2 | |
| - | - | - |
| 4.3.1, 4.3.2 | 5.3.1, 5.3.2 | |
| - | - | - |
| 4.4, 4.4.1 | 5.4, 5.4.1 | |
| - | - | - |
| 5 | 4.4, 4.4.1, | In 4.4.1, added normative text for |
| | 4.4.2.1, 4 | Transaction ID taken from old |
| | | 5.4.5. Did not include "Extension |
| | | Block" as generally usable |
| | | structure, but this decision is |
| | | subject to WG review. |
| - | - | - |
| 5.1 | 4.2 | Added normative text from old |
| | | 5.4.5. This text need review. |
| - | - | - |
| 5.2, 5.3 | 4.3 and | Capabilities were renamed to |
| | sub-sections | explicitly include "DSL" as part of |
| | | the name. OAM was renamed to line |
| | | testing, since that is all that is |
| | | included. |
| - | - | - |
| 5.4.1.1 | 5.2.3.2, | Merged into message format |
| | 5.3.3.2 | descriptions. |
| - | - | - |
| 5.4.2 | 5.2.3.2, | Contents scattered due to |
| | 5.2.3.3, and | separation of message format, |
| | sub-sections | procedures, TLV definitions. |
| - | - | - |
| 5.4.3 | 5.3.3.2 | |
| - | - | - |
| 5.4.3.1 | 6.1.2 | Provisioning message was not really |
| | | related to line provisioning. |
| - | - | - |
| 5.4.4 | Sub-sections | Contents scattered due to |
| | of 5.4.2 | separation of message format, |
| | | procedures, TLV definitions. |
| - | - | - |
| 5.4.5 | 6.1.1 | Normative text on Transaction ID, |
| | | discarding of messages removed to |
| | | 4.4 and 4.2 respectively. |
| - | - | - |
| 5.4.5.1 and | 6.2 and | |
| sub-sections | sub-sections | |
| - | - | - |
| 5.4.5.2 | 6.1.3 | |
| - | - | - |
| 5.5, 5.6 | 5.1.1, 5.1.2 | |
| - | - | - |
| 6, 7, 8, 9 | 7, 8, 9, 10 | |
+--------------+--------------+-------------------------------------+
Authors' Addresses Authors' Addresses
Sanjay Wadhwa Sanjay Wadhwa
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Phone: Phone:
Fax: Fax:
skipping to change at page 58, line 4 skipping to change at page 66, line 4
Jerome Moisand Jerome Moisand
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: jmoisand@juniper.net Email: jmoisand@juniper.net
Swami Subramanian
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Phone:
Fax:
Email: ssubramanian@juniper.net
Thomas Haag Thomas Haag
Deutsche Telekom Deutsche Telekom
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt, 64295 Darmstadt, 64295
Germany Germany
Phone: +49 6151 628 2088 Phone: +49 6151 628 2088
Fax: Fax:
Email: haagt@telekom.de Email: haagt@telekom.de
Norber Voigt Norbert Voigt
Siemens Nokia Siemens Networks
Siemensallee 1
Greifswald 17489
Germany
Phone: Email: norbert.voigt@nsn.com
Fax:
Email: norbert.voigt@siemens.com
Roberta Maglione Tom Taylor (editor)
Telecom Italia Huawei Technologies
via Reiss Romoli 274 Ottawa
Torino Canada
Italy
Phone: Email: tom111.taylor@bell.net
Email: roberta.maglione@telecomitalia.it
 End of changes. 510 change blocks. 
1762 lines changed or deleted 2157 lines changed or added

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