Network Working Group S. Wadhwa
Internet-Draft J. Moisand
Intended status: Standards Track Juniper Networks
Expires: January 12, 2011 T. Haag
Deutsche Telekom
N. Voigt
Nokia Siemens Networks
T. Taylor, Ed.
Huawei Technologies
July 11, 2010
Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-10
Abstract
This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a
multi-service reference architecture in order to perform QoS-related,
service-related and subscriber- related operations. Use cases for
ANCP are documented in RFC 5851. As well as describing the base ANCP
protocol, this document specifies capabilities for Digital Subscriber
Line (DSL) topology discovery, line configuration, and line testing.
The design of ANCP anticipates the specification in other documents
of extensions to the protocol to support additional ANCP protocol
capabilities covering other use cases and other technologies.
ANCP is based on GSMPv3 (RFC 3292), but with many modifications and
extensions, to the point that the two protocols are not
interoperable.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Wadhwa, et al. Expires January 12, 2011 [Page 1]
Internet-Draft ANCP Protocol July 2010
This Internet-Draft will expire on January 12, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Wadhwa, et al. Expires January 12, 2011 [Page 2]
Internet-Draft ANCP Protocol July 2010
Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 7
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 7
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 9
4. Access Node Control Protocol -- General Aspects . . . . . . . 9
4.1. Protocol Version . . . . . . . . . . . . . . . . . . . . . 10
4.2. ANCP Transport . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Use of the GSMPv3 Adjacency Protocol . . . . . . . . . . . 12
4.3.1. ANCP Adjacency Message Format . . . . . . . . . . . . 12
4.3.2. ANCP Adjacency Procedures . . . . . . . . . . . . . . 15
4.4. ANCP General Message Formats . . . . . . . . . . . . . . . 16
4.4.1. The ANCP Message Header . . . . . . . . . . . . . . . 17
4.4.2. The ANCP Message Body . . . . . . . . . . . . . . . . 20
5. ANCP Capabilities For Digital Subscriber Lines (DSL) . . . . . 22
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1. ATM-Specific Considerations . . . . . . . . . . . . . 22
5.1.2. Ethernet-Specific Considerations . . . . . . . . . . . 23
5.2. ANCP Based DSL Topology Discovery . . . . . . . . . . . . 23
5.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 24
5.2.3. Specification of the ANCP DSL Topology Discovery
Capability . . . . . . . . . . . . . . . . . . . . . . 25
5.3. ANCP based DSL Line Configuration . . . . . . . . . . . . 39
5.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 40
5.3.3. Specification of the ANCP DSL Line Configuration
Capability . . . . . . . . . . . . . . . . . . . . . . 42
5.4. ANCP Based DSL Line Testing Capability . . . . . . . . . . 46
5.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 46
5.4.2. Specification of the ANCP DSL Line Testing
Capability . . . . . . . . . . . . . . . . . . . . . . 47
6. Additional ANCP Messages and TLVs . . . . . . . . . . . . . . 50
6.1. Additional Messages and General Messaging Principles . . . 51
6.1.1. General Principles for the Design of ANCP Messages . 51
6.1.2. Provisioning Message . . . . . . . . . . . . . . . . . 51
6.1.3. Generic Response Message . . . . . . . . . . . . . . . 52
6.2. TLVs For General Use . . . . . . . . . . . . . . . . . . . 54
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
Wadhwa, et al. Expires January 12, 2011 [Page 3]
Internet-Draft ANCP Protocol July 2010
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
Wadhwa, et al. Expires January 12, 2011 [Page 4]
Internet-Draft ANCP Protocol July 2010
1. Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
This draft defines a new protocol, the Access Node Control Protocol
(ANCP), to realize a control plane between a service-oriented layer 3
edge device (the Network Access Server, NAS) and a layer 2 Access
Node (e.g., Digital Subscriber Line Access Module, DSLAM) in order to
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.
This specification assumes ANCP transport over TCP/IP. TCP
encapsulation for ANCP is as defined for GSMPv3 in [RFC3293]. ANCP
encapsulation directly over Ethernet and ATM as defined for GSMPv3 in
[RFC3293] is not considered.
ANCP uses a subset of GSMPv3 messages, message content, and
procedures to implement currently defined use cases. Additional ANCP
messages, message content, and procedures are specified in this
document and may also be specified in other documents extending ANCP.
The organization of this document is as follows:
o The next sub-section introduces some terminology that will be
useful in understanding the rest of the document.
o Section 3 provides a description of the access networks within
which ANCP will typically be deployed.
o Section 4 specifies generally applicable aspects of the ANCP
protocol.
o Section 5 describes and specifies the ANCP implementation of three
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.
Wadhwa, et al. Expires January 12, 2011 [Page 5]
Internet-Draft ANCP Protocol July 2010
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
the ANCP protocol based on pre-standards drafts are already
available. These early-draft implementations use protocol version/
sub-version 3.1. The standard ANCP protocol will use version/
sub-version 3.2 Adopting a new sub-version value provides a way to
disambiguate the two protocols and provides support for running a
pre-standard and a standards compliant ANCP implementation on any
given ANCP node. The mechanism used to identify the protocol
version/sub-version is part of the adjacency negotiation process and
it is described in detail in Section 4.3. NOTE: this mechanism does
not guarantee backwards compatibility of the published ANCP
specification with those early-draft implementations.
2.1. Terminology
Access Node (AN): Network device, usually located at a service
provider central office or street cabinet that terminates access
(local) loop connections from subscribers. In case the access
loop is a Digital Subscriber Line (DSL), the Access Node provides
DSL signal termination, and is referred to as DSL Access
Multiplexer (DSLAM).
Network Access Server (NAS): Network element which aggregates
subscriber traffic from a number of Access Nodes. The NAS is an
injection point for policy management and IP QoS in the access
network. It is also referred to as Broadband Network Gateway
(BNG) or Broadband Remote Access Server (BRAS).
Home Gateway (HGW): Network element that connects subscriber devices
to the Access Node and the access network. In the case of DSL,
the Home Gateway is a DSL network termination that could operate
either as a layer 2 bridge or as a layer 3 router. In the latter
case, such a device is also referred to as a Routing Gateway (RG).
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
of Ethernet frames). It excludes overhead that pertains to the
physical transmission mechanism (e.g. trellis coding in case of
Wadhwa, et al. Expires January 12, 2011 [Page 6]
Internet-Draft ANCP Protocol July 2010
DSL). This is defined in section 3.39 of ITU-T G.993.2.
DSL line (synch) rate: the total data rate of the DSL line,
including the overhead attributable to the physical transmission
mechanism.
DSL multi-pair bonding: method for bonding (or aggregating) multiple
xDSL lines into a single bi-directional logical link, henceforth
referred to in this draft as "DSL bonded circuit". DSL "multi-
pair" bonding allows an operator to combine the data rates on two
or more copper pairs, and deliver the aggregate data rate to a
single customer. ITU-T recommendations G.998.1 and G.998.2
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.1. ATM-based broadband aggregation
The end to end DSL network consists of network and application
service provider networks (NSP and ASP networks), regional/access
network, and customer premises network. Figure 1 shows ATM broadband
access network components.
The Regional/Access Network consists of the Regional Network, Network
Access Server, and the Access Network as shown in Figure 1. Its
Wadhwa, et al. Expires January 12, 2011 [Page 7]
Internet-Draft ANCP Protocol July 2010
primary function is to provide end-to-end transport between the
customer premises and the NSP or ASP. The Access Node terminates the
DSL signal. It may be in the form of a DSLAM in the central office,
or a remote DSLAM, or a Remote Access Multiplexer (RAM). The access
node is the first point in the network where traffic on multiple DSL
lines will be aggregated onto a single network.
The NAS performs multiple functions in the network. The NAS is the
aggregation point for subscriber traffic. It provides aggregation
capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network
and the NSP or ASP. These include traditional ATM-based offerings
and newer, more native IP-based services. This includes support for
Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet
(PPPoE), as well as direct IP services encapsulated over an
appropriate layer 2 transport.
Beyond aggregation, the NAS is also the injection point for policy
management and IP QoS in the Regional/Access Networks. To allow IP
QoS support over an existing non-IP-aware layer 2 access network
without using multiple layer 2 QoS classes, a mechanism based on
hierarchical scheduling is used. This mechanism, defined in
[TR_059], preserves IP QoS over the ATM network between the NAS and
the routing gateway (RG) at the edge of the subscriber network, by
carefully controlling downstream traffic in the NAS, so that
significant queuing and congestion does not occur further down the
ATM network. This is achieved by using a diffserv-aware hierarchical
scheduler in the NAS that will account for downstream trunk
bandwidths and DSL synch rates.
[RFC5851] provides detailed definition and functions of each network
element in the broadband reference architecture.
Wadhwa, et al. Expires January 12, 2011 [Page 8]
Internet-Draft ANCP Protocol July 2010
Access Customer
<--- Aggregation --> <------- Premises ------->
Network Network
+------------------+ +--------------------------+
+---------+ +---+ | +-----+ +------+ |-|+-----+ +---+ +---------+ |
NSP| | +-|NAS|-| |ATM |-|Access| | ||DSL |-|HGW|-|Subscriber||
---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices ||
|Broadband| | +---+ | +------+ | |+-----+ +----------+|
ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+
---+ | | +---+ | +--------------------------+
| | | +---+ | |+-----+ +---+ +----------+|
+---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber||
+---+ ||Modem| +---+ |Devices ||
|+-----+ +----------+|
+--------------------------+
HGW : Home Gateway
NAS : Network Access Server
Figure 1: ATM Broadband Aggregation Topology
3.2. Ethernet-based broadband aggregation
The Ethernet aggregation network architecture builds on the Ethernet
bridging/switching concepts defined in IEEE 802. The Ethernet
aggregation network provides traffic aggregation, class of service
distinction, and customer separation and traceability. VLAN tagging
defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as
standard virtualization mechanism in the Ethernet aggregation
network. The aggregation devices are "provider edge bridges" defined
in IEEE 802.ad. Stacked VLAN tags provide one possible way to create
equivalent of "virtual paths" and "virtual circuits" in the
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"
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
to bridge sessions from multiple subscribers behind a DSLAM into a
single VLAN in the aggregation network. This is N:1 VLAN allocation
model. Architectural and topological models of an Ethernet
aggregation network in context of DSL aggregation are defined in
[TR_101]
4. Access Node Control Protocol -- General Aspects
This section specifies aspects of the Access Node Control Protocol
(ANCP) that are generally applicable. As indicated above, ANCP is
Wadhwa, et al. Expires January 12, 2011 [Page 9]
Internet-Draft ANCP Protocol July 2010
derived from GSMPv3 [RFC3292]. Reference to [RFC3292] is made where
this is applicable, but ANCP introduces numerous modifications and
extensions to the basic GSMPv3 protocol. Moreover, ANCP uses only a
subset of the messages, message contents, and procedures defined for
GSMPv3.
The following are the only GSMPv3 [RFC3292] messages that are
currently used by ANCP.
Event Messages
* Port UP Message
* Port DOWN Message
These messages are used by the ANCP topology discovery capability.
Port Management Messages These messages are used by the ANCP "line
configuration" and ANCP "line testing" capabilities.
Adjacency Protocol Messages These messages are used to bring up a
protocol adjacency between a NAS and an AN.
ANCP modifies and extends some basic GSMPv3 procedures. These
modifications and extensions are summarized below, and described in
more detail in the succeeding sections.
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.
o The TCP connection establishment procedure in ANCP deviates
slightly from connection establishment in GSMPv3 as specified in
[RFC3293]. This is described in section Section 4.2.
o ANCP adds content to GSMPv3 messages in the form of additional
fixed fields and Type-Length-Value (TLV) structures. TLVs also
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.
4.1. Protocol Version
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
Wadhwa, et al. Expires January 12, 2011 [Page 10]
Internet-Draft ANCP Protocol July 2010
sub-field to 1. That is, the hexadecimal representation of the value
of the complete protocol version field MUST be 0x31.
RFC EDITOR'S NOTE: please change the value of sub-version in the
above paragraph to 2 (respectively a version field value of 0x32) in
the published specification. For an explanation see the Introduction
above.
4.2. ANCP Transport
This document specifies the use of TCP/IP for transport of ANCP
messages. Other specifications may introduce additional transports
in the future.
In the case of ATM access, a separate PVC (control channel)
capable of transporting IP may be configured between NAS and the
AN for ANCP messages.
In the case of an Ethernet access/aggregation network, a typical
practice is to send the Access Node Control Protocol messages over
a dedicated Ethernet virtual LAN (VLAN) using a separate VLAN
identifier (VLAN ID).
When transported over TCP, ANCP messages MUST use the encapsulation
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.
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encapsulation of ANCP Messages Over TCP/IP
The fields of the encapsulating header are as follows:
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).
Wadhwa, et al. Expires January 12, 2011 [Page 11]
Internet-Draft ANCP Protocol July 2010
Length: This 2-byte unsigned integer indicates the total length of
the ANCP message only. It does not include the 4-byte
encapsulating header.
The Access Node MUST initiate the TCP session to the NAS. This is
necessary to avoid static provisioning on the NAS for all the ANs
that are being served by the NAS. It is easier to configure a given
AN with the single IP address of the NAS that serves the AN. This is
a deviation from [RFC3293], which indicates that the controller
initiates the TCP connection to the switch.
The NAS MUST listen for incoming connections from the Access Nodes.
Port 6068 is used for TCP connection.
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.
4.3. Use of the GSMPv3 Adjacency Protocol
Section 11 of [RFC3292] defines the GSMPv3 adjacency protocol. ANCP
reuses the GSMPv3 adjacency protocol to synchronize the NAS and
Access Nodes and maintain the ANCP session. After the TCP connection
is established, adjacency protocol messages MUST be exchanged as
specified in Section 11 of [RFC3292], subject to the additional
specifications of this section. ANCP messages other than adjacency
protocol messages MUST NOT be sent until the adjacency protocol has
achieved synchronization.
4.3.1. ANCP Adjacency Message Format
The GSMPv3 adjacency message format defined in Section 11 of
[RFC3292] is modified and extended for ANCP as shown in Figure 3
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.
Wadhwa, et al. Expires January 12, 2011 [Page 12]
Internet-Draft ANCP Protocol July 2010
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
[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 fields added by ANCP are as follows:
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.
# of Caps: indicates the number of capability fields that follow.
Total Length: indicates the total number of bytes occupied by the
capability fields that follow.
Wadhwa, et al. Expires January 12, 2011 [Page 13]
Internet-Draft ANCP Protocol July 2010
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.
The format of a capability field is shown in Figure 4:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Capability Field
The sub-fields of this structure are as follows:
Capability Type: indicates the specific capability supported. An
IANA registry exists for values of this sub-field. The values
specified by this document are listed below.
Capability Length: the number of bytes of data contained in the
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
Wadhwa, et al. Expires January 12, 2011 [Page 14]
Internet-Draft ANCP Protocol July 2010
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
Wadhwa, et al. Expires January 12, 2011 [Page 15]
Internet-Draft ANCP Protocol July 2010
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
Wadhwa, et al. Expires January 12, 2011 [Page 16]
Internet-Draft ANCP Protocol July 2010
GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format as
shown in Figure 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ANCP General Message Format
4.4.1. The ANCP Message Header
The immediately visible differences from GSMPv3 are the subdivision
of the Version field into version and sub-version, and the
reallocation of space between Result and Code to enlarge the range
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.
A complete explanation of the header fields is as follows:
Version and Sub-version: The version of the ANCP protocol that was
agreed for the session during adjacency negotiation. For the
values that must be placed into these fields, see Section 4.1.
Message Type: The ANCP message type. Message type values are
registered in a common GSMPv3/ANCP IANA registry.
Result: The Result field derived from GSMPv3 [RFC3292]. Ignore
(0x0) is a new value added by ANCP. The remaining Result values
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.
Wadhwa, et al. Expires January 12, 2011 [Page 17]
Internet-Draft ANCP Protocol July 2010
Ignore: Res = 0x0 - Ignore this field on receipt and follow the
procedures specified for the received message type.
Nack: Res = 0x1 - Result code indicating that no response is
expected to the message other than in cases of failure caused
during the processing of the message contents or of the
contained directive(s).
AckAll: Res = 0x2 - Result code indicating that a response to the
message is requested in all cases.
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.
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.
Code: This field gives further information concerning the result in
a response message. It is mostly used to pass an error code in a
failure response but can also be used to give further information
in a success response message or an event message. In a request
message, the Code field is not used and MUST be set to zero.
ANCP implementations MAY use any of the Code values specified in
the IANA registry "Global Switch Management Protocol version 3
(GSMPv3) Failure Response Message Name Space" if they appear
applicable. In particular, the values:
2 Invalid request message (i.e., a properly formed message which
violates the protocol through its timing or direction of
transmission)
4 One or more of the specified ports do not exist
6 One or more of the specified ports are down
7 Invalid Partition ID
19 Out of resources (e.g. memory exhausted, etc.)
30 The limit on the maximum number of point-to-multipoint
connections that the switch can support has been reached
Wadhwa, et al. Expires January 12, 2011 [Page 18]
Internet-Draft ANCP Protocol July 2010
31 The limit on the maximum number of branches that the specified
point-to-multipoint connection can support has been reached
may unfortunately apply to ANCP usage, where "Port" is interpreted
to mean an access line or a Target as defined in Section 6.2.1.
Instead of the value:
3 The specified request is not implemented on this switch
specified by [RFC3292], this specification defines a new value:
81 Request message type not implemented
This value MAY be sent in a failure response from either the AN or
the NAS. This specification also defines the additional values:
82 Transaction identifier out of sequence
83 Malformed message
84 TLV or value not supported by negotiated capability set
ANCP extensions defining new code values SHOULD use the range 256
(0x100) through 511 (0x1FF) for this purpose.
The range of values from 256 to 4095 is reserved for IETF use.
Partition ID: This field is a 8 bit number which signifies a
partition on the AN.
The AN and NAS MAY agree on the partition ID using one of the
following possible options:
1 - The partition ID could be configured on the AN and learned by
the NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as
part of configuring the neighbor information.
Transaction ID: 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
Wadhwa, et al. Expires January 12, 2011 [Page 19]
Internet-Draft ANCP Protocol July 2010
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.
Unless otherwise specified, the default behaviour for all ANCP
responses is that the value of the Transaction ID MUST be copied
from the corresponding request message.
I flag and SubMessage Number: An ANCP implementation SHOULD set the
I Flag and subMessage Number fields to 1 to signify no
fragmentation.
Length: Length of the ANCP message including its header fields and
defined ANCP message body.
4.4.2. The ANCP Message Body
The detailed contents of the message payload portion of a given ANCP
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.
The general format of a TLV is shown in Figure 6:
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 (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: General TLV Format
The fields of a TLV are defined as follows:
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.
Wadhwa, et al. Expires January 12, 2011 [Page 20]
Internet-Draft ANCP Protocol July 2010
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.
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.
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.
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.
Unless otherwise specified, TLVs MAY be added to a message in any
order. If the recipient of a message does not understand a
particular TLV, it MUST silently ignore it.
A number of TLVs are specified in the remainder of this document.
4.4.2.1. Additional Conventions and General Requirements
Any field in a message that is inherited from GSMPv3 and is unused in
ANCP and any field that is explicitly shown as Reserved MUST be set
to all zeroes by the sender and MUST be ignored by the receiver.
Such fields could be assigned a specific purpose in a future
version of this specification.
Unused bits in a flag field are shown in figures as 'x'. The above
requirement (sender set to zero, receiver ignore) applies to such
unused bits.
Wadhwa, et al. Expires January 12, 2011 [Page 21]
Internet-Draft ANCP Protocol July 2010
5. ANCP Capabilities For Digital Subscriber Lines (DSL)
5.1. Overview
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.
When deploying value-added services across DSL access networks,
special attention is required to assure quality of service and
service control, which implies a tighter coordination between network
elements in the broadband access network without burdening the OSS
layer.
This document specifies basic ANCP capabilities for use specifically
in controlling Access Nodes serving DSL access (Tech Type = 0x05).
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.
The DSL capabilities specified in this section are:
DSL Topology Discovery: Dynamic discovery of access topology and DSL
line attributes by the NAS, to support tight QOS control in the
access network.
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.
DSL Line Testing: NAS controlled, on-demand access- line test
capability (rudimentary end-to-end OAM).
5.1.1. ATM-Specific Considerations
Topology discovery and line configuration involve the DSL line
attributes. For ATM based access networks, the DSL line on the DSLAM
is identified by the port and PVP/PVC corresponding to the
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
Wadhwa, et al. Expires January 12, 2011 [Page 22]
Internet-Draft ANCP Protocol July 2010
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.
The access loop circuit identifier can be carried as an ASCII string
in the ANCP messages. This allows ANCP to be decoupled from the
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.
5.1.2. Ethernet-Specific Considerations
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.
However, some carriers do not wish to use this "connection oriented"
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 have 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 5.2.3.3 defines TLVs to represent the "access loop circuit
ID".
5.2. ANCP Based DSL Topology Discovery
Wadhwa, et al. Expires January 12, 2011 [Page 23]
Internet-Draft ANCP Protocol July 2010
5.2.1. Goals
[TR_059] discusses various queuing/scheduling mechanisms to avoid
congestion in the access network while dealing with multiple flows
with distinct QoS requirements. Such mechanisms require that the NAS
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.
The following section describes ANCP messages that allow the Access
Node (e.g., DSLAM) to communicate access network topology information
and any corresponding updates to the NAS.
Some of the parameters that can be communicated from the DSLAM to the
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).
5.2.2. Message Flow
To provide expected service levels, the NAS needs to learn the
initial attributes of the DSL line before the subscriber can log in
and access the services provisioned for the subscription. When a DSL
line initially comes up or resynchronizes to a different rate, the
DSLAM generates and transmits an ANCP Port UP Event message to the
NAS. The extension field in the message carries the TLVs containing
DSL line specific parameters. Upon loss of signal on the DSL line,
an ANCP Port DOWN message is generated by the DSLAM and sent to the
NAS. Figure 7 summarizes the interaction.
Wadhwa, et al. Expires January 12, 2011 [Page 24]
Internet-Draft ANCP Protocol July 2010
1. NAS ------------------------ Access ----- Home ----- Subscriber
Node Gateway
<----- Port UP(Event Message) <----- DSL
(default line parameters) Signal
2. NAS ------------------------ Access ----- Home ----- Subscriber
Node Gateway
<----- Port UP (Event Message) <----- DSL
(updated line parameters) Resynch
3. NAS ------------------------ Access ----- Home ----- Subscriber
Node Gateway
<--- Port DOWN (Event Message) <---- DSL
Loss of Signal
Figure 7: ANCP Message Flow For DSL Topology Discovery
The Event message with Port UP message type (80) is used for
conveying DSL line attributes to the NAS. This message with relevant
extensions is defined in the next section.
5.2.3. Specification of the ANCP DSL Topology Discovery Capability
5.2.3.1. Protocol Requirements
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:
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).
o The procedures associated with these messages and their contents
(Section 5.2.3.2.1).
o Access-Loop-Circuit-ID TLV;
o Access-Loop-Remote-Id TLV;
o Access-Aggregation-Circuit-ID-Binary TLV;
Wadhwa, et al. Expires January 12, 2011 [Page 25]
Internet-Draft ANCP Protocol July 2010
o Access-Aggregation-Circuit-ID-ASCII TLV;
o DSL-Line-Attributes TLV;
o DSL-Type TLV;
o Actual-Net-Data-Upstream TLV;
o Actual-Net-Data-Rate-Downstream TLV;
o Minimum-Net-Data-Rate-Upstream TLV;
o Minimum-Net-Data-Rate-Downstream TLV;
o Attainable-Net-Data-Rate-Upstream TLV;
o Attainable-Net-Data-Rate-Downstream TLV;
o Maximum-Net-Data-Rate-Upstream TLV;
o Maximum-Net-Data-Rate-Downstream TLV;
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.
Wadhwa, et al. Expires January 12, 2011 [Page 26]
Internet-Draft ANCP Protocol July 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format Of the ANCP Port UP and Port DOWN Event Messages
For DSL Topology Discovery
See Section 4.4 for a description of the ANCP general message header.
The Message Type field MUST be set to 80 for Port UP, 81 for Port
DOWN. The 12 bit Code field MUST be set to 0. The 4 bit Result
field MUST be set to 0 (signifying Ignore). The 24-bit Transaction
Identifier field MUST be set to 0. Other fields in the general
header MUST be set as described in Section 4.4.
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.
The remaining message fields are described as follows:
Wadhwa, et al. Expires January 12, 2011 [Page 27]
Internet-Draft ANCP Protocol July 2010
Extension Flags: The flag bits denoted by 'x' are currently
unspecified and reserved.
Message Type: Message Type has the same value as in the general
header (i.e., 80 or 81).
Tech Type: MUST be set to 0x05 (DSL).
Block Length: unused, reserved.
# of TLVs: the number of TLVs that follow, not counting TLVs
encapsulated within other TLVs.
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).
TLVs: two or more TLVs to identify a DSL line and define its
characteristics.
5.2.3.2.1. Procedures
The GSMP Event message with Port UP message type (80) is used for
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
line change e.g. the line re-trains to a different rate or one or
more of the configured line attributes are administratively modified.
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
line goes down (idle or silent), the DSLAM SHOULD transmit an Event
message with Port DOWN message type (81) to the NAS. It is
recommended that the DSLAMs use a dampening mechanism per DSL line to
control the rate of state changes per DSL line, communicated to the
NAS.
If a Port UP message with a Result field set to 0 is received by the
NAS and the NAS is able to process the message correctly, the NAS
MUST NOT generate any ANCP message in response to the Port UP. If
the Port UP message received cannot be processed correctly by the NAS
(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.
In the case of bonded copper loops to the customer premise (as per
the DSL multi-pair bonding described by [G.988.1] and [G.988.2]), the
DSLAM MUST report the aggregate net data rate and other attributes
for the DSL bonded circuit (represented as a single logical port) to
Wadhwa, et al. Expires January 12, 2011 [Page 28]
Internet-Draft ANCP Protocol July 2010
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.
The definition of TLVs in the next section contains some additional
procedural information.
5.2.3.3. TLVs For DSL Topology Discovery
The following TLVs are currently defined for DSL Topology Discovery,
but may be reused for other capabilities.
5.2.3.3.1. Access-Loop-Circuit-ID TLV
Name: Access-Loop-Circuit-ID
Type: 0x0001
Description: 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].
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:
Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci
where the meanings of the terms should be obvious from their
names.
The Access-Node-Identifier uniquely identifies the Access Node in
the access network. The slot/port and VPI/VCI uniquely identify
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.
Wadhwa, et al. Expires January 12, 2011 [Page 29]
Internet-Draft ANCP Protocol July 2010
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:
Access-Node-Identifier " eth " slot "/" port [":" vlan-id]
This is a mandatory TLV.
Length: up to 63 bytes
Value: ASCII string
5.2.3.3.2. Access-Loop-Remote-Id TLV
Name: Access-Loop-Remote-Id
Type: 0x0002
Description: This is an optional TLV and 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 be 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
Value: ASCII string
5.2.3.3.3. Access-Aggregation-Circuit-ID-Binary TLV
Name: Access-Aggregation-Circuit-ID-Binary
Type: 0x0006
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.
Wadhwa, et al. Expires January 12, 2011 [Page 30]
Internet-Draft ANCP Protocol July 2010
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).
[Editor's Note: should we specify that the upper 20 bits are set
to zero? Which one is inner, which one is outer?]
Also, in case of an ATM aggregation network, where the DSLAM 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 TLV is optional.
Length: 8 bytes
Value: two 32 bit unsigned integers
5.2.3.3.4. Access-Aggregation-Circuit-ID-ASCII TLV
Name: Access-Aggregation-Circuit-ID-ASCII
Type: 0x0003
Description: This field contains information pertaining to an uplink
on the Access Node. For Ethernet access aggregation, assuming the
Access Node assigns VLAN tags (1:1 model), typical ABNF format for
the string is:
Access-Node-Identifier " eth " slot "/" port [":"
inner-vlan-id] [":" outer-vlan-id]
The slot/port corresponds to the ethernet uplink on the Access
Node towards the NAS.
For an ATM aggregation network, the typical format for the string
is:
Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci
This TLV allows the NAS to associate the information contained in
the ANCP messages to the DSL line on the Access Node.
Wadhwa, et al. Expires January 12, 2011 [Page 31]
Internet-Draft ANCP Protocol July 2010
If the Access Node inserts this string in the ANCP messages, when
referring to local loop characteristics (e.g. DSL line in case of
a DSLAM), then it should be able to map the information contained
in the string uniquely to the local loop (e.g. DSL line).
On the NAS, the information contained in this string can be used
to derive an aggregation-network-facing construct (e.g. an IP
interface) corresponding to the local loop (e.g. DSL line). The
association could be based on local configuration on the NAS.
The Access Node can also convey to the NAS the characteristics
(e.g., bandwidth) of the uplink on the Access Node. This TLV then
serves the purpose of uniquely identifying the uplink whose
characteristics are being defined. This version of the present
document does not specify the TLVs needed to convey the uplink
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.
Length: up to 63 bytes
Value: ASCII string
5.2.3.3.5. DSL-Line-Attributes TLV (Mandatory)
Name: DSL-Line-Attributes
Type: 0x0004
Description: This is a mandatory TLV providing attribute values for
a DSL line serving a subscriber.
Length: variable (up to 1024 bytes)
Value: one or more encapsulated TLVs corresponding to DSL line
attributes. The DSL-Line-Attributes TLV MUST contain the
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.
When the DSL-Line-Attributes TLV is present in a Port DOWN message
it SHOULD NOT include any TLVs other than DSL-Type and DSL-Line-
State.
Wadhwa, et al. Expires January 12, 2011 [Page 32]
Internet-Draft ANCP Protocol July 2010
5.2.3.3.6. TLVs Delivering Line Attributes
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.
5.2.3.3.6.1. DSL-Type TLV (Mandatory)
Name: DSL-Type
Type: 0x0091
Description: Indicates the type of transmission system in use. This
is a mandatory TLV.
Length: 4 bytes
Value: 32 bit unsigned integer
ADSL1 = 1
ADSL2 = 2
ADSL2+ = 3
VDSL1 = 4
VDSL2 = 5
SDSL = 6
UNKNOWN = 7
5.2.3.3.6.2. Actual-Net-Data-Rate-Upstream TLV
Name: Actual-Net-Data-Rate-Upstream
Type: 0x0081
Description: Actual upstream net data rate on a DSL line. This is a
mandatory TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
Wadhwa, et al. Expires January 12, 2011 [Page 33]
Internet-Draft ANCP Protocol July 2010
5.2.3.3.6.3. Actual-Net-Data-Rate-Downstream TLV
Name: Actual-Net-Data-Rate-Downstream
Type: 0x0082
Description: Actual downstream net data rate on a DSL line. This is
a mandatory TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.4. Minimum-Net-Data-Rate-Upstream TLV
Name: Minimum-Net-Data-Rate-Upstream
Type: 0x0083
Description: Minimum upstream net data rate desired by the operator.
This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.5. Minimum-Net-Data-Rate-Downstream TLV
Name: Minimum-Net-Data-Rate-Downstream
Type: 0x0084
Description: Minimum downstream net data rate desired by the
operator. This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.6. Attainable-Net-Data-Rate-Upstream TLV
Name: Attainable-Net-Data-Rate-Upstream
Type: 0x0085
Wadhwa, et al. Expires January 12, 2011 [Page 34]
Internet-Draft ANCP Protocol July 2010
Description: Maximum net upstream rate that can be attained on the
DSL line. This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.7. Attainable-Net-Data-Rate-Downstream TLV
Name: Attainable-Net-Data-Rate-Downstream
Type: 0x0086
Description: Maximum net downstream rate that can be attained on the
DSL line. This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.8. Maximum-Net-Data-Rate-Upstream TLV
Name: Maximum-Net-Data-Rate-Upstream
Type: 0x0087
Description: Maximum net upstream data rate desired by the operator.
This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
5.2.3.3.6.9. Maximum-Net-Data-Rate-Downstream TLV
Name: Maximum-Net-Data-Rate-Downstream
Type: 0x0088
Description: Maximum net downstream data rate desired by the
operator. This is an optional TLV.
Length: 4 bytes
Value: Rate in Kbits/s as a 32 bit unsigned integer
Wadhwa, et al. Expires January 12, 2011 [Page 35]
Internet-Draft ANCP Protocol July 2010
5.2.3.3.6.10. Minimum-Net-Low-Power-Data-Rate-Upstream TLV
Name: Minimum-Net-Low-Power-Data-Rate-Upstream
Type: 0x0089
Description: Minimum net upstream 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.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
Wadhwa, et al. Expires January 12, 2011 [Page 36]
Internet-Draft ANCP Protocol July 2010
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.
Wadhwa, et al. Expires January 12, 2011 [Page 37]
Internet-Draft ANCP Protocol July 2010
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
Wadhwa, et al. Expires January 12, 2011 [Page 38]
Internet-Draft ANCP Protocol July 2010
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
Wadhwa, et al. Expires January 12, 2011 [Page 39]
Internet-Draft ANCP Protocol July 2010
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.
Wadhwa, et al. Expires January 12, 2011 [Page 40]
Internet-Draft ANCP Protocol July 2010
+----------+ +-----+ +-----+ +-------+ +-----------+
|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
Wadhwa, et al. Expires January 12, 2011 [Page 41]
Internet-Draft ANCP Protocol July 2010
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.
Wadhwa, et al. Expires January 12, 2011 [Page 42]
Internet-Draft ANCP Protocol July 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|x|x|x|x|x|x|x| Duration | Function | X-Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
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
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
fields in the general header MUST be set as described in Section 4.4.
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 Port, Port Session Number, and Event Sequence Number fields are
not used by the DSL Line Configuration capability and MUST be
Wadhwa, et al. Expires January 12, 2011 [Page 43]
Internet-Draft ANCP Protocol July 2010
considered reserved. The handling of unused/reserved fields is
described in Section 4.4.2.1.
The remaining message fields are described as follows:
R Flag: not used by ANCP.
Additional Port Management flags: the flag bits marked 'x' following
the R flag are not used by ANCP.
Duration: not used for DSL line configuration.
Function: action to be performed. For DSL line configuration,
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).
X-Function: qualifies the action set by Function. For DSL line
configuration, this field MUST be set to 0.
Event Flags: not used by ANCP.
Flow Control Flags: not used by ANCP.
Extension Flags: the flag bits denoted by 'x' before the Message
Type field are reserved for future use.
Message Type: Message Type has the same value as in the general
header (i.e., 32).
Tech Type: MUST be set to 0x05 (DSL).
Block Length: unused, reserved.
# of TLVs: the number of TLVs that follow, not counting TLVs
encapsulated within other TLVs.
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).
TLVs: two or more TLVs to identify a DSL line and configure its
service data.
Wadhwa, et al. Expires January 12, 2011 [Page 44]
Internet-Draft ANCP Protocol July 2010
5.3.3.3. Procedures
Section 5.3.2 Describes the circumstances under which the NAS sends a
Port Management message to the AN to configure DSL service parameters
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.
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.
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.
5.3.3.4. TLVs For DSL Line Configuration
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).
Name: Service-Profile-Name
Type: 0x0005
Description: Reference to a pre-configured profile on the DSLAM that
contains service specific data for the subscriber.
Length: up to 64 bytes
Wadhwa, et al. Expires January 12, 2011 [Page 45]
Internet-Draft ANCP Protocol July 2010
Value: ASCII string containing the profile name (which the NAS
learns from a policy server after a subscriber is authorized).
5.4. ANCP Based DSL Line Testing Capability
In a mixed Ethernet and ATM access network (including the local
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 the NAS with an access
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.
5.4.1. Message Flow
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.
+-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)|
+----------------+
Port Management Message
(Remote Loopback ATM loopback
Trigger Request) OR EFM Loopback
1. ----------------> 2. --------->
<--------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
Figure 13: Message Flow For ANCP based OAM
Wadhwa, et al. Expires January 12, 2011 [Page 46]
Internet-Draft ANCP Protocol July 2010
5.4.2. Specification of the ANCP DSL Line Testing Capability
5.4.2.1. Protocol Requirements
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:
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.4.2.2).
o The procedures associated with this message and its contents
(Section 5.4.2.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 OAM-Loopback-Test-Parameters TLV;
o Opaque-Data TLV;
o OAM-Loopback-Test-Response-String TLV.
If not otherwise indicated, the TLVs listed above are defined in
Section 5.4.2.4.
5.4.2.2. Message Format
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:
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.
o The Function field MUST be set to 9 (Remote Loopback). (The
X-Function field continues to be 0.)
o The appended TLVs in the extension value field include testing-
related TLVs rather than subcriber service information.
Wadhwa, et al. Expires January 12, 2011 [Page 47]
Internet-Draft ANCP Protocol July 2010
5.4.2.3. Procedures
The ANCP Port Management message as described in Section 5.4.2.2 MAY
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.
The Access Node SHOULD generate a Port Management response when it
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.
1280 (0x500): Specified access line does not exist
1281 (0x501): Loopback test timed out
1282 (0x502): Reserved
1283 (0x503): DSL line status showtime
1284 (0x504): DSL line status idle
1285 (0x505): DSL line status silent
1286 (0x506): DSL line status training
1287 (0x507): DSL line integrity error
1288 (0x508): DSLAM resource not available
1289 (0x509): Invalid test parameter
All other fields including the appended TLVs MUST be copied from the
request, except that the OAM-Loopback-Test-Parameters TLV MUST NOT
appear in the response and the OAM-Loopback-Test-Response-String TLV
SHOULD appear in the response.
Section 5.4.2.4 contains additional procedures relating to specific
TLVs.
Wadhwa, et al. Expires January 12, 2011 [Page 48]
Internet-Draft ANCP Protocol July 2010
5.4.2.4. TLVs For the DSL Line Test Capability
The following TLVs have been defined for use with the DSL line
testing capability.
5.4.2.4.1. OAM-Loopback-Test-Parameters TLV
Name: OAM-Loopback-Test-Parameters
Type: 0x0007
Description: Parameters related to a 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: 2 bytes
Value: two 1 byte fields described below (listed in order of most to
least significant).
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.
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.
The OAM-Loopback-Test-Parameters TLV is illustrated in Figure 14
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 = 0x0007 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Timeout | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wadhwa, et al. Expires January 12, 2011 [Page 49]
Internet-Draft ANCP Protocol July 2010
Figure 14: The OAM-Loopback-Test-Parameters TLV
5.4.2.4.2. Opaque-Data TLV
Name: Opaque-Data
Type: 0x0008
Description: This is an optional TLV. If it is present in the
request message, the DSLAM SHOULD reflect it back in the response
unmodified.
Length: 8 bytes
Value: Two 32 bit unsigned integers inserted by the NAS (not to be
interpreted by the DSLAM, but just reflected back in the
response).
5.4.2.4.3. OAM-Loopback-Test-Response-String TLV
Name: OAM-Loopback-Test-Response-String
Type: 0x0009
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.
Length: up to 128 bytes
Value: ASCII string.
6. Additional ANCP Messages and TLVs
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.
Wadhwa, et al. Expires January 12, 2011 [Page 50]
Internet-Draft ANCP Protocol July 2010
6.1. Additional Messages and General Messaging Principles
6.1.1. General Principles for the Design of ANCP Messages
The GSMPv3 protocol [RFC3292] allows for two messaging constructs to
support request/response interaction:
a. The same message type is used for both the request message and
the response message. The Result and Code field settings are
used to differentiate between request and response messages.
b. The request and response messages use two different message
types.
The first approach is illustrated by the protocol specifications in
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.
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.
The Transaction ID field is used to distinguish between request
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.
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).
6.1.2. Provisioning Message
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.
Wadhwa, et al. Expires January 12, 2011 [Page 51]
Internet-Draft ANCP Protocol July 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Format of the Provisioning 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. 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.
Message Type: MUST be set to 93.
Result: MUST be set to 0x0 (Ignore).
Code: MUST be set to zero.
Transaction ID: MUST be populated with a non-zero value chosen in
the manner described in Section 4.4.1.
If the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any
response.
If not otherwise specified, if the AN fails to process the message
successfully it MUST send a Generic Response message (Section 6.1.3)
indicating failure and providing appropriate diagnostic information.
6.1.3. Generic Response Message
This section defines the Generic Response message. The Generic
Response message may be specified as the appropriate response to a
message defined in an extension to ANCP, instead of a more specific
response message. As a general guideline, specification of the
Wadhwa, et al. Expires January 12, 2011 [Page 52]
Internet-Draft ANCP Protocol July 2010
Generic Response message as a response is appropriate where no data
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
reason for failure and a limited amount of diagnostic data.
Depending on the particular use case, the Generic Response message
MAY be sent by either the NAS or the AN.
The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this
case, the sender MUST set the Transaction ID field in the header and
the Message Type field within the Status-Info TLV to zeroes. The
receiver MAY record the information contained in the Status-info TLV
for management use.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP/IP Encapsulating Header (Section 4.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ANCP General Message Header |
+ (Section 4.4) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-Info TLV |
~ (Section 6.2.3) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Wadhwa, et al. Expires January 12, 2011 [Page 53]
Internet-Draft ANCP Protocol July 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x1000 |Length = Circuit-ID Length + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Example of Target TLV For Single Access Line
Wadhwa, et al. Expires January 12, 2011 [Page 54]
Internet-Draft ANCP Protocol July 2010
6.2.2. Command TLV
Name: Command
Type: 0x0011
Description: The Command TLV (0x0011) is intended to be a general
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.
Length: Variable, depending on the specific contents.
Value: Command information as defined for each message type. The
field can include sub-TLVs. The contents of this TLV MUST be
specified as one "command" or alternatively a sequence of one or
more "commands", each beginning with a one-byte Command Code and
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.
6.2.3. Status-Info TLV
Name: Status-Info
Type: 0x0106
Description: The Status-Info-TLV is intended to be a general
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.
Length: Variable, depending on the specific contents.
Value: The following fixed fields. In addition, sub-TLVs may be
appended to provide further diagnostic information.
Wadhwa, et al. Expires January 12, 2011 [Page 55]
Internet-Draft ANCP Protocol July 2010
Reserved: see Section 4.4.2.1 for handling of reserved fields.
Msg Type: Message Type of the request for which this TLV is
providing diagnostics.
Error Message Length: Number of bytes in the error message,
excluding padding. This MAY be zero if no error message is
provided.
Error Message: Human-readable string providing information about
the warning or error condition. Padded with zeroes as
necessary to extend to a four-byte word boundary.
The following TLVs are RECOMMENDED to be appended 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
unknown or unavailable port.
* Code value 84: the TLV that is unsupported or contains the
unsupported value.
Figure 18 illustrates the Status-Info TLV.
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: The Status-Info TLV
7. IANA Considerations
RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this
specification.
Wadhwa, et al. Expires January 12, 2011 [Page 56]
Internet-Draft ANCP Protocol July 2010
7.1. Summary
This section requests the following IANA actions:
o addition of message types to the GSMPv3 Message Type Name Space
registry;
o addition of a result type to the GSMPv3 Result Type Name Space
registry; [Editor's Note: may need an ANCP registry instead.
Coordination between the two protocols is unnecessary because of
ANCP's reorganization of the Result field.]
o extension of limits [Editor's Note: assuming we are allowed to do
this!] and addition of failure codes to the GSMPv3 Failure
Response Message Name Space registry;
o establishment of the following new ANCP registries:
ANCP Function Codes; [Editor's Note: GSMPv3 has no function
code registry, so this one might as well belong to ANCP.
Coordination between the two protocols is unnecessary because
of ANCP's reorganization of the Function field.]
ANCP Technology Types;
ANCP Command Codes;
ANCP TLV Types;
ANCP Capabilities.
7.2. IANA Actions
IANA is requested to add a new message category to the GSMPv3 Message
Type Name Space registry: "Access Network Control Protocol (ANCP)
Messages". IANA is requested to add the following entries under that
category:
+------------------+----------------+--------+-----------+
| Message Name | Message Number | Status | Reference |
+------------------+----------------+--------+-----------+
| Generic Response | 91 | | RFCXXXX |
| Provisioning | 93 | | RFCXXXX |
+------------------+----------------+--------+-----------+
IANA is requested to implement the following modification to the
General Switch Management Protocol version 3 (GSMPv3) Result Type
Name Space registry:
Wadhwa, et al. Expires January 12, 2011 [Page 57]
Internet-Draft ANCP Protocol July 2010
+--------------+-----------------------+-----------+
| Result Value | Result Type Name | Reference |
+--------------+-----------------------+-----------+
| 0 | Ignore (was Reserved) | RFCXXXX |
+--------------+-----------------------+-----------+
IANA is requested to implement the following modifications to the
GSMPv3 Failure Response Message Name Space:
o Add the following note to the registry:
This registry is shared with the Access Node Control Protocol
(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.
o Add entries to the failure response message name table as
indicated.
o Replace the ranges of unassigned codes at the end of the failure
response message name table as indicated.
+----------+------------------------+---------------+
| Range | Registration Procedure | Notes |
+----------+------------------------+---------------+
| 256-4095 | IETF Consensus | ANCP use only |
+----------+------------------------+---------------+
Wadhwa, et al. Expires January 12, 2011 [Page 58]
Internet-Draft ANCP Protocol July 2010
+-------+-----------------------------------------------+-----------+
| 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 | |
+----------------+-----------------------------------+-----------+
Wadhwa, et al. Expires January 12, 2011 [Page 59]
Internet-Draft ANCP Protocol July 2010
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:
Wadhwa, et al. Expires January 12, 2011 [Page 60]
Internet-Draft ANCP Protocol July 2010
+--------------+----------------------------------------+-----------+
| 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 | | |
+--------------+----------------------------------------+-----------+
Wadhwa, et al. Expires January 12, 2011 [Page 61]
Internet-Draft ANCP Protocol July 2010
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]
9. Acknowledgements
The authors would like to thank everyone that has provided comments
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,
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel
Platnic.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002.
[RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch
Wadhwa, et al. Expires January 12, 2011 [Page 62]
Internet-Draft ANCP Protocol July 2010
Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", RFC 3293, June 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
10.2. Informative References
[G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair
bonding", 2005.
[G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding,", 2005.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", RFC 5713, January 2010.
[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.
[TR_059] Anschutz, T., "DSL Forum TR-059, DSL Evolution -
Architecture Requirements for the Support of QoS-Enabled
IP Services", September 2003.
[TR_092] "DSL Forum TR-092, Broadband Remote access server
requirements document", 2005.
[TR_101] Cohen et al, "Architecture & Transport: "Migration to
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.
Wadhwa, et al. Expires January 12, 2011 [Page 63]
Internet-Draft ANCP Protocol July 2010
+--------------+--------------+-------------------------------------+
| -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. |
Wadhwa, et al. Expires January 12, 2011 [Page 64]
Internet-Draft ANCP Protocol July 2010
| - | - | - |
| 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
Sanjay Wadhwa
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Phone:
Fax:
Email: swadhwa@juniper.net
Jerome Moisand
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Phone:
Fax:
Email: jmoisand@juniper.net
Wadhwa, et al. Expires January 12, 2011 [Page 65]
Internet-Draft ANCP Protocol July 2010
Thomas Haag
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64295
Germany
Phone: +49 6151 628 2088
Fax:
Email: haagt@telekom.de
Norbert Voigt
Nokia Siemens Networks
Siemensallee 1
Greifswald 17489
Germany
Email: norbert.voigt@nsn.com
Tom Taylor (editor)
Huawei Technologies
Ottawa
Canada
Email: tom111.taylor@bell.net
Wadhwa, et al. Expires January 12, 2011 [Page 66]
