Network Working Group S. Wadhwa
Internet-Draft J. Moisand
Intended status: Standards Track S. Subramanian
Expires: September 10, 2009 Juniper Networks
T. Haag
T-systems
N. Voigt
Siemens
R. Maglione
Telecom Italia
March 9, 2009
Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-05
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
Wadhwa, et al. Expires September 10, 2009 [Page 1]
Internet-Draft ancp protocol March 2009
and restrictions with respect to this document.
Abstract
This document describes proposed extensions to the GSMPv3 protocol to
allow its use in a broadband environment, as a control plane between
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g.
NAS). These proposed extensions are required to realize a protocol
for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK].
The resulting protocol with the proposed extensions to GSMPv3
[RFC3292] is referred to as "Access Node Control Protocol" (ANCP).
This document currently focuses on specific use cases of access node
control mechanism for topology discovery, line configuration, and OAM
as described in ANCP framework document [ANCP-FRAMEWORK]. It is
intended to be augmented by additional protocol specification for
future use cases considered in scope by the ANCP charter.
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
in detail. Illustrative text for the use-cases is included here to
help the protocol implementer understand the greater context of ANCP
protocol interactions.
Wadhwa, et al. Expires September 10, 2009 [Page 2]
Internet-Draft ancp protocol March 2009
Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 5
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 5
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7
4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. ANCP based Access Topology Discovery . . . . . . . . . . . 8
4.2.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9
4.3. ANCP based Line Configuration . . . . . . . . . . . . . . 10
4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
4.4. ANCP based Transactional Multicast . . . . . . . . . . . . 13
4.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 14
4.5. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 15
5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 15
5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 19
5.2. ANCP Connection keep-alive . . . . . . . . . . . . . . . . 21
5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 21
5.4. GSMP Message Extensions for Access Node Control . . . . . 24
5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 24
5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 25
5.4.3. Line Configuration Extensions . . . . . . . . . . . . 35
5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 38
5.4.5. Multicast Extensions . . . . . . . . . . . . . . . . . 41
5.4.5.1. General well known TLVs . . . . . . . . . . . . . 42
5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 42
5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 43
5.4.5.1.3. Status-Info TLV . . . . . . . . . . . . . . . 44
5.4.5.2. Multicast Replication Control Message . . . . . . 45
5.4.5.3. Multicast Status Message . . . . . . . . . . . . . 51
5.5. ATM-specific considerations . . . . . . . . . . . . . . . 53
5.6. Ethernet-specific considerations . . . . . . . . . . . . . 54
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
7. Security Considerations . . . . . . . . . . . . . . . . . . . 59
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.1. Normative References . . . . . . . . . . . . . . . . . . . 60
9.2. Informative References . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Wadhwa, et al. Expires September 10, 2009 [Page 3]
Internet-Draft ancp protocol March 2009
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
DSL is a widely deployed access technology for Broadband Access for
Next Generation Networks. Several specifications like [TR-059],
[TR-058], [TR-092] describe possible architectures for these access
networks. In the scope of these specifications are the delivery of
voice, video and data services.
When deploying value-added services across DSL access networks,
special attention regarding quality of service and service control is
required, which implies a tighter coordination between network
elements in the broadband access network without burdening the OSS
layer.
This draft defines extensions and modifications to GSMPv3 (specified
in [RFC3292]) and certain new mechanisms to realize a control plane
between a service-oriented layer 3 edge device (the NAS) and a layer2
Access Node (e.g. DSLAM) in order to perform QoS-related, service-
related and subscriber-related operations. The control protocol as a
result of these extensions and mechanisms is referred to as "Access
Node Control Protocol" (ANCP).
ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP
encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3
encapsulation directly over Ethernet and ATM as defined in [RFC3293]
is not considered for ANCP.
ANCP uses a subset of GSMPv3 messages to implement currently defined
use-cases. These relevant GSMPv3 messages are identified in section
Section 5. GSMPv3 procedures with suitable extensions, as used by
ANCP, are described in sections Section 5.1, Section 5.2 and
Section 5.3. GSMPv3 general extensions and GSMPv3 message specific
extensions required by ANCP are described in sub-sections of
Section 5.4. In addition to specifying extensions and modifications
to relevant GSMP messages applicable to ANCP, this draft also defines
the usage of these messages by ANCP. Not all the fields in relevant
GSMP messages are used by ANCP. This draft indicates the value that
ANCP should set for the fields in these GSMP messages.
Wadhwa, et al. Expires September 10, 2009 [Page 4]
Internet-Draft ancp protocol March 2009
2.1. Terminology
o 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).
o 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).
o Home Gateway (HGW): Network element that connects subscriber
devices to the Access Node and the access network. In case of
DSL, the Home Gateway is a DSL network termination that could
either operate 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).
o 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
DSL). This is defined in section 3.39 of ITU-T G.993.2.
o DSL line (synch) rate: the total data rate of the DSL line,
including the overhead attributable to the physical transmission
mechanism.
o 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.
3. Broadband Access Aggregation
3.1. ATM-based broadband aggregation
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
Wadhwa, et al. Expires September 10, 2009 [Page 5]
Internet-Draft ancp protocol March 2009
network components.
The Regional/Access Network consists of the Regional Network, Network
Access Server, and the Access Network as show in Figure 1. Its
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 could consist of DSLAM in the central office, or
remote DSLAM, or a Remote Access Multiplexer (RAM). 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 the 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, NAS is also the injection point for policy
management and IP QoS in the Regional/Access Networks. In order 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 RGs 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.
[ANCP-FRAMEWORK] provides detailed definition and functions of each
network element in the broadband reference architecture.
Wadhwa, et al. Expires September 10, 2009 [Page 6]
Internet-Draft ancp protocol March 2009
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
Wadhwa, et al. Expires September 10, 2009 [Page 7]
Internet-Draft ancp protocol March 2009
4.1. Overview
A dedicated control protocol between NAS and access nodes can
facilitate "NAS managed" tight QOS control in the access network,
simplified OSS infrastructure for service management, optimized
multicast replication to enable video services over DSL, subscriber
statistics retrieval on the NAS for accounting purposes, and fault
isolation capability on the NAS for the underlying access technology.
This dedicated control plane is referred to as "Access Node Control
Protocol" (ANCP). This document specifies relevant extensions to
GSMPv3 as defined [RFC3292] to realize ANCP.
Following sections discuss the use of ANCP for implementing:
o Dynamic discovery of access topology by the NAS to provide tight
QOS control in the access network.
o Pushing to the access-nodes, subscriber and service data retrieved
by the NAS from an OSS system (e.g. radius server), to simplify
OSS infrastructure for service management.
o Optimized, "NAS controlled and managed" multicast replication by
access-nodes at L2 layer.
o NAS controlled, on-demand access-line test capability (rudimentary
end-to-end OAM).
In addition to DSL, alternate broadband access technologies (e.g.
Metro-Ethernet, Passive Optical Networking, WiMax) will have similar
challenges to address, and could benefit from the same approach of a
control plane between a NAS and an Access Node (e.g. OLT), providing
a unified control and management architecture for multiple access
technologies, hence facilitating migration from one to the other
and/or parallel deployments.
GSMPv3 is an ideal fit for implementing ANCP. It is extensible and
can be run over TCP/IP, which makes it possible to run over different
access technologies.
4.2. ANCP based Access Topology Discovery
4.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
Wadhwa, et al. Expires September 10, 2009 [Page 8]
Internet-Draft ancp protocol March 2009
information required is somewhat dynamic in nature (e.g. DSL sync
rate, and therefore also the net data rate), hence cannot come from a
provisioning and/or inventory management OSS system. Some of the
information varies less frequently (e.g. capacity of a DSLAM uplink),
but nevertheless needs to be kept strictly in sync between the actual
capacity of the uplink and the image the NAS has of it.
Following section describes ANCP messages that allow the Access Node
(e.g. DSLAM) to communicate to the NAS, access network topology
information and any corresponding updates.
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).
4.2.2. Message Flow
When a DSL line initially comes up or resynchronizes to a different
rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message
to the NAS. The extension field in the message carries the TLVs
containing DSL line specific parameters. On a loss of signal on the
DSL line, a GSMP PORT DOWN message is generated by the DSLAM to the
NAS. In order to provide expected service level, NAS needs to learn
the initial attributes of the DSL line before the subscriber can log
in and access the provisioned services for the subscriber. Figure 2
summarizes the interaction.
Wadhwa, et al. Expires September 10, 2009 [Page 9]
Internet-Draft ancp protocol March 2009
<----- Port UP(EVENT Message) <----- DSL
(default line parameters) Signal
1. NAS ------------------ Access ----------- Home ----- Subscriber
Node Gateway
<----- Port UP (EVENT Message) <----- DSL
(updated line parameters) Resynch
2. NAS ------------------ Access ----------- Home ------ Subscriber
Node Gateway
<--- Port DOWN (EVENT Message) <---- DSL
Loss of Signal
3. NAS ----------------- Access ------------- Home ----- Subscriber
Node Gateway
Figure 2: Message flow (ANCP mapping) for 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 section Section 5.4.2.
4.3. ANCP based Line Configuration
4.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 could then query a
subscriber management OSS system (e.g. RADIUS server) to retrieve
subscriber authorization data (service profiles, aka user
entitlement). Most of such service mechanisms are typically enforced
by the NAS itself, but there are a few cases where it might be useful
to push such service parameter to the DSLAM for local enforcement of
a mechanism (e.g. DSL-related) on the corresponding subscriber line.
One such example of a service parameter that can be pushed to the
DSLAM for local enforcement is DSL "interleaving delay". Longer
interleaving delay (and hence stringent error correction) is required
for a video service to ensure better video "quality of experience",
whereas for a VoIP service or for "shoot first" gaming service, a
very short interleaving delay is more appropriate. Another relevant
application is downloading per subscriber multicast channel
entitlement information in IPTV applications where the DSLAM is
performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS
could achieve the goal of pushing line configuration to the DSLAM by
an interoperable and standardized protocol.
Wadhwa, et al. Expires September 10, 2009 [Page 10]
Internet-Draft ancp protocol March 2009
If a subscriber wants to choose a different service, it can require
an OPEX 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 B2B interactions.
The best way to change line parameters would be by using profiles.
These profiles (DSL profiles for different services) are pre-
configured on the DSLAMs. The NAS can then indicate a reference to
the right DSL profile via ANCP. Alternatively, discrete DSL
parameters can also be conveyed by the NAS in ANCP.
4.3.2. Message Flow
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 GSMP Port Management messages. The
NAS may get such line configuration data from a policy server (e.g.
RADIUS). Figure 3 summarizes the interaction.
Wadhwa, et al. Expires September 10, 2009 [Page 11]
Internet-Draft ancp protocol March 2009
1.DSL Signal
<-----------
2. Port UP (EVENT Message)
(Access Topology Discovery)
<----------------
3. PPP/DHCP Session
<--------------------------------
4. Authorization
& Authentication
<-------------------
Port Management Message
(Line Configuration)
5. -------->
+----------+ +-----+ +-----+ +-------+ +-----------+
|Radius/AAA|---| NAS |-----| AN |----| Home |----|Subscriber |
|Policy | +-----+ +-----+ |Gateway| +-----------+
|Server | +-------+
+----------+
Figure 3: Message flow - ANCP mapping for Initial Line Configuration
The NAS may update the line configuration due to a subscriber service
change (e.g. triggered by the policy server). Figure 4 summarizes
the interaction.
Wadhwa, et al. Expires September 10, 2009 [Page 12]
Internet-Draft ancp protocol March 2009
1. PPP/DHCP Session
<------------------------------------------
+-----------+ 2. Service On Demand
| |<-----------------------------------------------
| Web portal|
| OSS etc | 3.Change of 4.Port Management
| | Authorization Message
|Radius AAA | --------> (Updated Line
| Policy | Config - New Profile)
| | ------------->
| | +------+ +-------+ +---------+ +----------+
| |----| NAS |-----| AN |---| Home |--|Subscriber|
| | +------+ +-------+ | Gateway | +----------+
+-----------+ +---------+
Figure 4: Message flow - ANCP mapping for Updated Line Configuration
The format of relevant extensions to port management message is
defined in section Section 5.4.3. The line configuration models
could be viewed as a form of delegation of authorization from the NAS
to the DSLAM.
4.4. ANCP based Transactional Multicast
4.4.1. Goals
Typical IP multicast in access networks involves the NAS terminating
user requests for receiving multicast channels via IGMP. The NAS
authorizes the subscriber, and dynamically determines the multicast
subscription rights for the subscriber. Based on the user's
subscription, the NAS can replicate the same multicast stream to
multiple subscribers. This leads to a waste of access bandwidth if
multiple subscribers access network services via the same access-node
(e.g. DSLAM). The amount of multicast replication is of the order
of number of subscribers rather than the number of access-nodes. It
is ideal for NAS to send a single copy of the multicast stream to a
given access-node, and let the access-node perform multicast
replication by layer2 means (e.g. ATM point-to-multipoint cell
replication or Ethernet data-link bridging) for subscribers behind
the access-node. However, operationally, NAS is the ideal choice to
handle subscriber management functions (authentication,
authorization, accounting and address management), multicast policies
such as per-channel authorization, and complex multicast routing
protocols. Therefore, some means is needed for the NAS to setup
multicast replication state in the access-nodes. In ATM access
networks, ANCP can be used by the NAS to setup P2MP cross-connects in
the DSLAMs. Protocol support for this use-case is defined in section
Wadhwa, et al. Expires September 10, 2009 [Page 13]
Internet-Draft ancp protocol March 2009
Section 5.4.5
4.4.2. Message Flow
The Multicast Replication Control Message is sent by the NAS to the
AN with a directive to either join or leave one or more multicast
flows. The AN will use a Multicast Status Message when conveying the
outcome of the directive. The message flows in Figure 5 illustrates
the behavior of the AN in case of receiving a Multicast Replication
Control Message.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast-Replication-Crl |
| | |(Target,add, Flowi..Flowj) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<==========================+ |
| | | Multicast-Status |
| | |-------------------------->|
| | | |
| | | Multicast-Replication-Crl |
| | |(Target,delete,Flowi.Flowj)|
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Multicast-Status |
| | |-------------------------->|
Figure 5: NAS-Controlled Multicast Replication
4.5. ANCP based OAM
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 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 the result of the triggered loopback test.
Wadhwa, et al. Expires September 10, 2009 [Page 14]
Internet-Draft ancp protocol March 2009
In case of ATM based local-loop the ANCP operation can trigger the
access-node to generate ATM (F4/F5) loopback cells on the local loop.
In case of Ethernet, the access-node can trigger an Ethernet loopback
message(per EFM OAM) on the local-loop.
4.5.1. Message Flow
"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
format of relevant extensions to port management message is defined
in section The format of relevant extensions to port management
message is defined in section Section 5.4.4. Figure 6 summarizes the
interaction.
Port Management Message
(Remote Loopback ATM loopback
Trigger Request) OR EFM Loopback
1. ----------------> 2. --------->
<--------+
+-------------+ +-----+ +-------+ +----------------+
|Radius/AAA |----|NAS |-------| DSLAM |-----------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ |Routing Gateway)|
+----------------+
3. <---------------
Port Management Message
(Remote Loopback Test Response)
Figure 6: Message Flow: ANCP based OAM
5. Access Node Control Protocol (ANCP)
ANCP uses a subset of GSMPv3 messages described in [RFC3292] to
implement currently defined use-cases. GSMPv3 general message
format, used by all GSMP messages other than adjacency protocol
messages, is defined in section 3.1.1 of GSMPv3 [RFC3292]. ANCP
modifies this base GSMPv3 message format. The modified GSMPv3
message format is defined as follows:
Wadhwa, et al. Expires September 10, 2009 [Page 15]
Internet-Draft ancp protocol March 2009
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 7: Modified GSMPv3 message format
The 8-bit version field in the base GSMPv3 message header is split
into two 4 bit fields for carrying the version and a sub-version of
the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP
protocol. An ANCP implementation SHOULD always set the version field
to 3, and the sub-version field to 1. The Result field in the
message header has been modified to be 4 bits long, and the Code
field to be 12 bits long.
Version:
The version number of the GSMP protocol being used in this
session. ANCP uses version 3.
Sub-Version:
The sub-version number of the GSMP protocol being used in this
session. ANCP uses sub-version 1 of the GSMP protocol.
Result:
The Result field derived from GSMP [RFC3292] has the following
codes:
Ignore:
Res = 0x00 - Ignore this field on receipt and follow the
procedures specified for the received message type.
Nack:
Wadhwa, et al. Expires September 10, 2009 [Page 16]
Internet-Draft ancp protocol March 2009
Res = 0x01 - 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 that
of the contained directive(s).
AckAll:
Res = 0x02 - Result code indicating that a response to the
message is requested in all cases. It is specifically
intended to be used in some cases for Request messages only,
and is not to be used in Event messages.
Success:
Res = 0x03 - Set by receiver to indicate successful
execution of all directives in the corresponding Request
message.
Failure:
Res = 0x4 - Set by receiver in the Response message if one
or more directives in the corresponding Request message
fails.
Message-Type:
The GSMP and ANCP message type.
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
Wadhwa, et al. Expires September 10, 2009 [Page 17]
Internet-Draft ancp protocol March 2009
message, the code field is not used and is set to zero. In an
adjacency protocol message, the Code field is used to determine
the function of the message.
Partition ID:
This field is a 8 bit number which signifies a partition on the
AN. [ TBD How AN and NAS agree on the partition numbers. Possible
options:
1 - The partition ID could be configured on the AN and learnt by
NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as
part of configuring the neighbor information.]
Transaction ID:
24-bit field set by the sender of a Request message to associate a
Response message with the original Request message. The receiver
of a Request message reflects the transaction ID from the Request
message in the corresponding Response message. For event
messages, the transaction identifier SHOULD be set to zero. The
Transaction Identifier is not used, and the field is not present,
in the adjacency protocol. The specific use of transaction ID as
applicable to multicast use case is defined in Section 5.4.5
I flag:
An ANCP implementation SHOULD set "I" and subMessage fields to 1
to signify no fragmentation.
Length:
Length of the GSMP message including its header fields and defined
GSMP message body.
Additional General Message Information:
o Any field in a GSMP message that is unused or defined as
"reserved" MUST be set to zero by the sender and ignored by the
receiver;
o Flags that are undefined will be designated as: x: reserved.
Following are the relevant GSMPv3 messages defined in [RFC3292], that
are currently used by ANCP. Other than the message types explicitly
listed below, no other GSMPv3 messages are used by ANCP currently.
Wadhwa, et al. Expires September 10, 2009 [Page 18]
Internet-Draft ancp protocol March 2009
o Event Messages
* Port UP Message
* Port DOWN Message
These messages are used by ANCP topology discovery use-case.
o Port Management Messages
* These messages are used by ANCP "line configuration" use-case
and ANCP OAM use-case.
o Adjacency Protocol Messages
* These messages are used to bring up a protocol adjacency
between a NAS and an AN.
ANCP modifies and extends few 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 5.3
o TCP connection establishment procedure in ANCP deviates slightly
from the connection establishment in GSMPv3 as specified in
[RFC3293]. This is described in section Section 5.1
o ANCP makes GSMPv3 messages extensible and flexible by adding a
general "extension block" to the end of the relevant GSMPv3
messages. The "extension block" contains a TLV structure to carry
information relevant to each ANCP use-case. The format of the
"extension block" is defined in section Section 5.4.1.1.
o
5.1. ANCP/TCP connection establishment
ANCP will use TCP for exchanging protocol messages [RFC3293]. defines
the GSMP message encapsulation for TCP. The TCP session is initiated
from the DSLAM (access node) to the NAS (controller). This is
necessary to avoid static provisioning on the NAS for all the DSLAMs
that are being served by the NAS. It is easier to configure a given
DSLAM with the single IP address of the NAS that serves the DSLAM.
This is a deviation from [RFC3293] which indicates that the
Wadhwa, et al. Expires September 10, 2009 [Page 19]
Internet-Draft ancp protocol March 2009
controller initiates the TCP connection to the switch.
When GSMP messages are sent over a TCP connection a four-byte TLV
header field is prepended to the GSMP message to provide delineation
of GSMP messages within the TCP stream.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GSMPv3 with TCP/IP Encapsulation message format
Type
This 2-byte field indicates the type code of the following
message. The type code for GSMP messages is 0x88-0C (i.e., the
same as GSMP's Ethertype).
Length
This 2-byte unsigned integer indicates the total length of the
GSMP message only. It does not include the 4-byte TLV header.
NAS listens for incoming connections from the access nodes. Port
6068 is used for TCP connection. Adjacency protocol messages, which
are used to synchronize the NAS and access-nodes and maintain
handshakes, are sent after the TCP connection is established. ANCP
messages other than adjacency protocol messages may be sent only
after the adjacency protocol has achieved synchronization.
In the case of ATM access, a separate PVC (control channel) capable
of transporting IP would be configured between NAS and the DSLAM for
ANCP messages.
In 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).
Wadhwa, et al. Expires September 10, 2009 [Page 20]
Internet-Draft ancp protocol March 2009
5.2. ANCP Connection keep-alive
GSMPv3 defines an adjacency protocol. The adjacency protocol is used
to synchronize states across the link, to negotiate which version of
the GSMP protocol to use, to discover the identity of the entity at
the other end of a link, and to detect when it changes. GSMP is a
hard state protocol. It is therefore important to detect loss of
contact between switch and controller, and to detect any change of
identity of switch or controller. No protocol messages other than
those of the adjacency protocol may be sent across the link until the
adjacency protocol has achieved synchronization. There are no
changes to the base GSMP adjacency protocol for implementing ANCP.
The NAS will set the M-flag in the SYN message (signifying it is the
master). Once the adjacency is established, periodic adjacency
messages (type ACK) are exchanged. The default ACK interval as
advertised in the adjacency messages is 10 sec for ANCP. It SHOULD
be configurable and is an implementation choice. It is recommended
that both ends specify the same timer value. However, it is not
necessary for the timer values to match.
The GSMP adjacency message defined in [RFC3292] is extended for ANCP
and is shown in section 5.3 immediately following this section. The
8-bit "version" field in the adjacency protocol messages is modified
to carry the version and sub-version of the GSMP protocol for version
negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol.
The semantics and suggested values for Code, "Sender Name", "Receiver
Name", "Sender Instance", and "Receiver Instance" fields are as
defined in [RFC3292]. The "Sender Port", and "Receiver Port" should
be set to 0 by both ends. The pType field should be set to 0. The
pFlag should be set to 1.
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 would continue to listen for
new connection requests. The DSLAM will try to re-establish the TCP
connection and both sides will attempt to re-establish the adjacency.
The handling defined above will need some modifications when ANCP
graceful restart procedures are defined. These procedures will be
defined in a separate draft.
5.3. Capability negotiation
The adjacency message as defined in [RFC3292] is extended to carry
technology specific "Capability TLVs". Both the NAS and the access
Wadhwa, et al. Expires September 10, 2009 [Page 21]
Internet-Draft ancp protocol March 2009
node will advertise supported capabilities in the originated
adjacency messages. If a received adjacency message indicates
absence of support for a capability that is supported by the
receiving device, it will turn off the capability locally and will
send an updated adjacency message with the capability turned off to
match the received capability set. This process will eventually
result in both sides agreeing on the minimal set of supported
capabilities. The adjacency will not come up unless the capabilities
advertised by the controller and the controlled device match.
After initial synchronization, if at anytime a capability mismatch is
detected, the adjacency will be brought down (RSTACK will be
generated by the device detecting the mismatch), and synchronization
will be re-attempted.
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 TLVs | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capability TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
The format of capability TLV is:
Wadhwa, et al. Expires September 10, 2009 [Page 22]
Internet-Draft ancp protocol March 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Capability TLV
The Tech Type field type indicates the technology to which the
capability extension applies. For access node control in case of DSL
networks, new type "DSL" is proposed. The value for this field is
0x05. This is the first available value in the range that is not
currently allocated. It will need to be reserved with IANA.
Capability length is the number of actual bytes contained in the
value portion of the TLV. The TLV is padded to a 4-octet alignment.
Therefore, a TLV with no data will contain a zero in the length field
(if capability data is three octets, the length field will contain a
three, but the size of the actual TLV is eight octets). Capability
data field can be empty if the capability is just a boolean. In case
the capability is a boolean, it is inferred from the presence of the
TLV (with no data).
Capability data provides the flexibility to advertise more than mere
presence or absence of a capability. Capability types can be
registered with IANA. Following capabilities are defined for ANCP as
applied to DSL access:
1. Capability Type : Dynamic-Topology-Discovery = 0x01
Length (in bytes) : 0
Capability Data : NULL
2. Capability Type : Line-Configuration = 0x02
Length (in bytes) : 0
Capability Data : NULL
3. Capability Type : Transactional-Multicast = 0x03 (controller i.e.
NAS terminates IGMP messages from subscribers, and via l2 control
protocol, signals state to the access-nodes (e.g. DSLAMs) to
enable layer2 replication of multicast streams. In ATM access
network this implies that NAS instructs the access-node to setup
Wadhwa, et al. Expires September 10, 2009 [Page 23]
Internet-Draft ancp protocol March 2009
a P2MP cross-connect. The details of this will be covered in a
separate ID.
Length (in bytes) : 0
Capability Data : NULL
4. Capability Type : OAM = 0x04
Length (in bytes) : 0
Capability Data : NULL
5.4. GSMP Message Extensions for Access Node Control
5.4.1. General Extensions
Extensions to GSMP messages for various use-cases of "Access Node
Control" mechanism are defined in sections Section 5.4.2 to
Section 5.4.5. However, sub-sections Section 5.4.1.1 below define
extensions to GSMP that have general applicability.
5.4.1.1. Extension TLV
In order to provide flexibility and extensibility certain GSMP
messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
[RFC3292] have been modified to include an extension block that
follows a TLV structure. Individual messages in the following
sections describe the usage and format of the extension block.
All Extension TLVs will be designated as follow:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Extension TLV
x: Reserved Flags
Wadhwa, et al. Expires September 10, 2009 [Page 24]
Internet-Draft ancp protocol March 2009
These are generally used by specific messages and will be
defined in those messages.
Message Type
An 8-bit field corresponding to the message type where the
extension block is used.
Tech Type
An 8-bit field indicating the applicable technology type value.
The Message Type plus the Tech Value uniquely define a single
Extension Type and can be treated as a single 16 bit extension
type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL
technology.
0x00 Extension block not in use.
0x01 - 0x04 Already in use by various technologies
0x05 DSL
0x06 - 0xFE Reserved
0xFF Base Specification Use
Block Length
A 8-bit field indicating the length of the Extension Value
field in bytes. When the Tech Type = 0x00, the length value
MUST be set to 0.
Extension Value
A variable length field that is an integer number of 32 bit
words long. The Extension Value field is interpreted according
to the specific definitions provided by the messages in the
following sections..
5.4.2. Topology Discovery Extensions
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.
Wadhwa, et al. Expires September 10, 2009 [Page 25]
Internet-Draft ancp protocol March 2009
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.
Not all the fields in GSMP Event message are applicable to ANCP. The
fields that are not applicable MUST be set to zero by the ANCP sender
and ignored by the ANCP receiver. The fields in the PORT UP and PORT
DOWN messages to be set by the ANCP sender, and corresponding
handling by the ANCP receiver is described below.
The version field MUST be set to 3, and the sub field MUST be set to
1. As defined in [RFC3292], the one byte Message Type field MUST be
set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event
Message. The 8 bit Code field MUST be set to 0. The 4 bit Result
field MUST be set to 0 (signifying Ignore.) 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 Error Message (TBD)
containing the reason of the failure. The 24-bit Transaction
Identifier field MUST be set to 0. The "I" bit and the SubMessage
field MUST be set to 1 to signify no fragmentation. The Length field
is two bytes and MUST contain the length of the message (including
header and the payload) in bytes.
The "Port" field, "Port Session Number" field and "Event Sequence
Number" field are 4 bytes each, and MUST be set to 0 by the ANCP
sender. LABEL field in event messages is defined as a TLV in
[RFC3292]. ANCP does NOT use the Label TLV. In both PORT UP and
PORT DOWN event messages an ANCP sender MUST treat the Label field,
immediately following the "Event Sequence Number" field, as a fixed 8
byte field, and MUST set these 8 bytes to 0. The receiver MUST NOT
interpret the LABEL field as a TLV and MUST ignore the 8 bytes
immediately following the "Event Sequence Number" field. In future
versions of ANCP, if necessary, the un-used fields in GSMP Event
message, which do not have ANCP specific semantics, can be used
partially or completely, by re-naming appropriately, and associating
valid semantics with these fields.
The Tech Type field is extended with new type "DSL". The value for
this field is 0x05.
In case of bonded copper loops to the customer premise (as per DSL
Wadhwa, et al. Expires September 10, 2009 [Page 26]
Internet-Draft ancp protocol March 2009
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 the
NAS in a PORT UP message. Any change in the aggregate net data rate
of the "DSL bonded circuit" (due to a change in net data rate of
individual constituent DSL lines or due to change in state of the
individual constituent DSL lines) MUST be reported by the DSLAM to
the NAS in a PORT UP message. The DSLAM MUST also report the
"aggregate" state of the "DSL bonded circuit" to the NAS via PORT UP
and PORT DOWN messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Label +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
The format of the "Extension Value" field for Tech Type "DSL" is as
follows :
Wadhwa, et al. Expires September 10, 2009 [Page 27]
Internet-Draft ancp protocol March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Extension Value
The "Extension Value" contains one or more TLVs to identify a DSL
line and define its characteristics. A TLV can consist of multiple
sub-TLVs. First 2 byte of the "Extension Value" contains the number
of TLVs that follow. The next 2 bytes contain the total length of
the TLVs carried in the extension block in bytes (existing "Block
Length" field in the GSMP message is limited to 255 bytes and is not
sufficient).
General format of a TLV is :
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: General TLV
The value field in each TLV is padded to a 4-octet alignment. The
Length field in each TLV contains the actual number of bytes in the
TLV (not including the padding if present). If a TLV is not
understood by the NAS, it is silently ignored. Currently defined
types start from 0x01.
Following TLVs are currently defined:
1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and
contains an identifier of the subscriber's connection to the
access node (i.e. "local loop"). The "local loop" can be ATM
based or Ethernet based. The "Access Loop Circuit ID" has local
significance at the access node. The exact usage on the NAS is
Wadhwa, et al. Expires September 10, 2009 [Page 28]
Internet-Draft ancp protocol March 2009
beyond the scope of this document. The format used for "local
loop" identification in ANCP messages MUST be identical to what
is used by the access nodes in subscriber signaling messages when
the access nodes act as "signaling relay agents" as outlined in
[RFC3046] and [TR-101].
Length : (up to 63 bytes)
Value : ASCII string
For an ATM based local loop the string consists of slot/port
and VPI/VCI information corresponding to the subscriber's DSL
connection. Default syntax for the string inserted by the
access node as per [TR-101] is:
"Access-Node-Identifier atm slot/port:vpi.vci"
The Access-Node-Identifier uniquely identifies the access node
in the access network. The slot/port and VPI/VCI uniquely
identifies 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.
For local loop which is Ethernet based (and tagged), the
string consists of slot/port and VLAN tag corresponding to the
subscriber. Default syntax for the string inserted by the
access node as per [TR-101] is:
"Access-Node-Identifier eth slot/port[:vlan-id]"
2. Type (Access-Loop-Remote-Id = 0x02): 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 is similar to what is used by the access nodes in
subscriber signaling messages when the access nodes act as
"signaling relay agents" as outlined in [RFC3046] and [TR-101].
Length : (up to 63 bytes)
Value : ASCII string
3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06)
Length : (8 bytes)
Wadhwa, et al. Expires September 10, 2009 [Page 29]
Internet-Draft ancp protocol March 2009
Value : two 32 bit integers
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
This TLV can carry 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
integer (least significant bits) contains a 12 bit VLAN
identifier (which is part of the VLAN tag defined by IEEE
802.1Q).
Also, in case of an ATM aggregation network, where the DSLAM
is directly connected to the NAS (without an intermediate ATM
switch), the two values can contain VPI and VCI on the DSLAM
uplink (and can uniquely identify the DSL line on the DSLAM).
This is optional.
4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03)
Length : (up to 63 bytes)
Value : ASCII string
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 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.
Wadhwa, et al. Expires September 10, 2009 [Page 30]
Internet-Draft ancp protocol March 2009
For an ATM aggregation network, 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.
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. A separate set of sub-TLVs will be defined for the
uplink characteristics (TBD).
This TLV is optional.
5. Type (DSL Line Attributes = 0x04):
Length : variable (up to 1024 bytes)
Value : This is a mandatory TLV and consists of one or more
Sub-TLVs corresponding to DSL line attributes. No sub-TLVs
other than the "DSL type" and "DSL line state" SHOULD be
included in a PORT DOWN message.
The general format of the sub-TLVs is identical to the general
TLV format. The value field in each sub-TLV is padded to a
4-octet alignment. The Length field in each sub-TLV contains
the actual number of bytes in the TLV (not including the
padding if present). Current defined sub-TLV types are start
from 0x81.
Wadhwa, et al. Expires September 10, 2009 [Page 31]
Internet-Draft ancp protocol March 2009
Following sub-TLVs are currently defined :
+ Type (DSL-Type = 0x91) : Defines the type of transmission
system in use. This is a mandatory TLV.
Length : (4 bytes)
Value : (Transmission system : ADSL1 = 0x01, ADSL2 =
0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL =
0x06, UNKNOWN = 0x07).
+ Type (Actual-Net-Data-Upstream = 0x81): Actual upstream net
data rate on a DSL line. This is a mandatory TLV.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Actual-Net-Data-Rate-Downstream = 0x82) : Actual
downstream net data rate on a DSL line. This is a
mandatory TLV.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Minimum-Net-Data-Rate-Upstream = 0x83) : Minimum net
data rate desired by the operator. This is optional.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Minimum-Net-Data-Rate-Downstream = 0x84) : Minimum
net data rate desired by the operator. This is optional.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Attainable-Net-Data-Rate-Upstream = 0x85) : Maximum
net upstream rate that can be attained on the DSL line.
This is an optional TLV.
Length : (4 bytes)
Wadhwa, et al. Expires September 10, 2009 [Page 32]
Internet-Draft ancp protocol March 2009
Value : (Rate in Kb/sec)
+ Type (Attainable-Net-Data-Rate-Downstream = 0x86) : Maximum
net downstream rate that can be attained on the DSL line.
This is an optional TLV.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Maximum-Net-Data-Rate-Upstream = 0x87) : Maximum net
data rate desired by the operator. This is optional.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Maximum-Net-Data-Rate-Downstream = 0x88) : Maximum
net data rate desired by the operator. This is optional.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Minimum-Net-Low-Power-Data-Rate-Upstream = 0x89) :
Minimum net data rate desired by the operator in low power
state. This is optional.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Minimum-Net-Low-Power-Data-Rate-Downstream = 0x8A) :
Minimum net data rate desired by the operator in low power
state. This is optional.
Length : (4 bytes)
Value : (Rate in Kb/sec)
+ Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum
one way interleaving delay. This is optional.
Length : (4 bytes)
Wadhwa, et al. Expires September 10, 2009 [Page 33]
Internet-Draft ancp protocol March 2009
Value : (Time in msec)
+ Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value
corresponding to the interleaver setting. This is
optional.
Length : (4 bytes)
Value : (Time in msec)
+ Type (Maximum-Interleaving-Delay-Downstream = 0x8D) :
maximum one way interleaving delay. This is optional.
Length : (4 bytes)
Value : (Time in msec)
+ Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value
corresponding to the interleaver setting. This is
optional.
Length : (4 bytes)
Value : (Time in msec)
+ Type (DSL line state = 0x8F) : The state of the DSL line.
For PORT UP message, at this time, the TLV is optional
(since the message type implicitly conveys the state of the
line). For PORT DOWN, the TLV is mandatory, since it
further communicates the state of the line as IDLE or
SILENT.
Length : (4 bytes)
Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 }
+ Type (Access Loop Encapsulation = 0x90) : 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 can be optionally
indicated.
Length : (3 bytes)
Wadhwa, et al. Expires September 10, 2009 [Page 34]
Internet-Draft ancp protocol March 2009
Value : The three bytes (most to least significant) and
valid set of values for each byte are defined below.
Data Link (1 byte): {ATM AAL5 = 0, ETHERNET = 1}
Encaps 1 (1 byte): {
NA = 0,
Untagged Ethernet = 1,
Single-tagged Ethernet = 2}
Encaps 2 (1 byte):{
NA = 0,
PPPoA LLC = 1
PPPoA NULL = 2,
IPoA LLC = 3,
IPoA NuLL = 4,
Ethernet over AAL5 LLC with FCS = 5,
Ethernet over AAL5 LLC without FCS = 6,
Ethernet over AAL5 NULL with FCS = 7,
Ethernet over AAL5 NULL without FCS = 8}
If this TLV is present, the Data Link protocol MUST be
indicated as defined above. However, 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
5.4.3. Line Configuration Extensions
The Port Management message format defined in [RFC3292] has been
modified to contain an extension block (described above in section
Section 5.4.1.1) at the end of the message. Also, the original two
byte Function field has been modified to contain one byte for the
Function field indicating a specific action to be taken by the
recipient of the message, and one byte for X-Function field, which
could further qualify the action specified in the Function field.
Wadhwa, et al. Expires September 10, 2009 [Page 35]
Internet-Draft ancp protocol March 2009
Any Function specific data MUST be carried in the extension block.
Not all the fields in GSMP Port Management message are applicable to
ANCP. The fields that are not applicable MUST be set to zero by the
ANCP sender and ignored by the ANCP receiver.
The NAS uses the extension block in the Port Management messages to
convey service attributes of the DSL lines to the DSLAM. TLVs are
defined for DSL line identification and service data for the DSL
lines. Port number is set to 0 in the message. A new action type
"Configure Connection Service Data" (value 0x8) is defined. The
"Function" field is set to the action type. This action type
indicates to the device being controlled (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). For the action type "Configure Connection Service
Data", X-Function field MUST be set to 0. The Tech Type field is
extended with new type "DSL". The value for this field is 0x05.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
The format of the "Extension Value" field is as follows:
Wadhwa, et al. Expires September 10, 2009 [Page 36]
Internet-Draft ancp protocol March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Extension Value
The "Extension Value" field contains one or more TLVs containing DSL
line identifier and desired service attributes of the the DSL line.
First 2 byte of the "Extension Value" contains the number of TLVs
that follow. The next 2 bytes contain the total length of the
extension block in bytes (existing "Block Length" field in the GSMP
message is limited to 255 bytes and is not sufficient).
General format of a TLV is:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: General TLV
The value field is padded to a 4-octet alignment. The Length field
in each TLV contains the actual number of bytes in the TLV (not
including the padding if present). If a TLV is not understood by the
access-node, it is silently ignored. Depending upon the deployment
scenario, the NAS may specify "Access Loop Circuit-ID" or the "Access
Aggregation Circuit-ID") as defined in section Section 5.4.1.
Following TLVs can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section Section 5.4.1
Wadhwa, et al. Expires September 10, 2009 [Page 37]
Internet-Draft ancp protocol March 2009
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
section Section 5.4.1
o Type (Service-Profile-Name = 0x05): Reference to a pre-configured
profile on the DSLAM that contains service specific data for the
subscriber.
Length : (up to 64 bytes)
Value : ASCII string containing the profile name (NAS learns
from a policy server after a subscriber is authorized).
In future, more TLVs MAY be defined for individual service
attributes of a DSL line (e.g. rates, interleaving delay,
multicast channel entitlement access-list etc).
5.4.4. OAM Extensions
GSMP "Port Management" message (type 32) SHOULD be used by the NAS to
trigger access node to run a loopback test on the local loop. The
message format is defined in section Section 5.4.2. The version
field SHOULD be set to 3 and sub-version field SHOULD be set to 1.
The remaining fields in the GSMP header have standard semantics. The
function type used in the request message SHOULD be set to "remote
loopback" (type = 0x09). The port, "port session number", "event
sequence number", duration, "event flags", "flow control flags" and
code fields SHOULD all be set to 0. The result field SHOULD be set
to "AckAll" to indicate requirement for the access node to send a
success or failure response. The transaction ID SHOULD contain a
sequence number inserted by the NAS in each request that it
generates.
Not all the fields in GSMP Port Management message are applicable to
ANCP. The fields that are not applicable MUST be set to zero by the
ANCP sender and ignored by the ANCP receiver.
The extension field format is also defined above in section
Section 5.4.2. The extension value field can contain one or more
TLVs including the access-line identifier on the DSLAM and OAM test
characteristics desired by the NAS.
The TLV format is defined above in section Section 5.4.2. The value
field is padded to a 4-octet alignment. The Length field in each TLV
contains the actual number of bytes in the TLV (not including the
padding if present). If a TLV is not understood by the NAS, it is
silently ignored. Depending upon the deployment scenario, the NAS
may specify "Access Loop Circuit-ID" or the "Access Aggregation
Circuit-ID") as defined in section Section 5.4.1. Following TLVs can
Wadhwa, et al. Expires September 10, 2009 [Page 38]
Internet-Draft ancp protocol March 2009
appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
section Section 5.4.1
o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to
loopback test. This is an optional TLV. If this TLV is not
present in the request message, the DSLAM SHOULD use locally
determined default values for the test parameters.
Length : (4 bytes)
Value : two 1 byte numbers described below (listed in order of
most to least significant). Thus, the 4 bytes consist of 1
byte of Count, followed by 1 byte of Timeout, followed by two
pad bytes of zero.
+ Count (1 byte) : 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 the request for a loopback test, if the
received test parameters contain an out of range value for
the "count" field. The DSLAM MAY optionally send a failure
response to the NAS with the code "invalid test parameter".
+ Timeout (1 byte) : Upper bound on the time in seconds that
the NAS would wait for a response from the DSLAM. If the
total time taken by the DSLAM to complete a test with
requested parameters, exceeds the specified "timeout" value,
it can choose to omit the generation of a response to the
NAS. DSLAM SHOULD use a locally determined value for the
"timeout", if the received value of the "timeout" parameter
is 0.
o Type (Opaque-Data = 0x08) : This is an optional TLV. If present
in the request message, the DSLAM SHOULD reflect it back in the
response unmodified
Wadhwa, et al. Expires September 10, 2009 [Page 39]
Internet-Draft ancp protocol March 2009
Length : (8 bytes)
Value : Two 32 bit integers inserted by the NAS (not to be
interpreted by the DSLAM, but just reflected back in the
response).
The access node generates a success or failure response when it deems
the loopback test to be complete. "Port Management" message (type
32) is used. The result field SHOULD be set to success or failure.
The function type SHOULD be set to 0x09. The transaction ID SHOULD
be copied from the sequence number contained in the corresponding
request. The other parameters not explicitly defined here SHOULD be
set as specified in the request message above. The code field SHOULD
be set to a value in the range 0x500 to 0x5ff (to be reserved with
IANA) to indicate the status of the executed test. The valid values
defined are (can be extended in future):
0x500 : Specified access line does not exist
0x501 : Loopback test timed out
0x502 : Reserved
0x503 : DSL line status showtime
0x504 : DSL line status idle
0x505 : DSL line status silent
0x506 : DSL line status training
0x507 : DSL line integrity error
0x508 : DSLAM resource not available
0x509 : Invalid test parameter
The Extension value can contain one or more TLVs including the TLV to
identify the access line on which the test was performed, and details
from executing the test. The access line identifier SHOULD be
identical to what was contained in the request. The relevant TLVs
are:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
Section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section Section 5.4.1
Wadhwa, et al. Expires September 10, 2009 [Page 40]
Internet-Draft ancp protocol March 2009
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in
section Section 5.4.1
o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the
request reflected back by the DSLAM.
Length : (up to 8 bytes)
Value : Two 32 bit integers as received in the request (opaque
to the DSLAM).
o Type (OAM-Loopback-Test-Response-String = 0x09)
Length : (up to 128 bytes)
Value : 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.
5.4.5. Multicast Extensions
The format of the ANCP Multicast message starts with the common GSMP
header as in the case of the existing ANCP implementation. Following
is the format of this header:
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 18: ANCP Header
Wadhwa, et al. Expires September 10, 2009 [Page 41]
Internet-Draft ancp protocol March 2009
The Result field takes one of the values defined in Section 5.
The Transaction Identifier field is used to distinguish between
request messages and to associate a response message to a request.
Applications that require such response correlation MUST set the
Transaction Identifier to a value in the range (1, 2^24 - 1). When
used in this manner, the Transaction Identifier sequencing MUST be
maintained independently for each ANCP adjacency and per message
type. Furthermore, it SHOULD be incremented linearly for each new
message of the given type, cycling back to 1 after running the full
range. Message types not requiring response message correlation
SHOULD set the Transaction Id field to 0x0. In the event of an ANCP
transport protocol failure, all pending ANCP messages destined to the
disconnected recipient can be discarded until the transport is re-
established following which the Transaction Identifier is re-
initialized.
The value of the Transaction Identifier in a Response message MUST be
set to that of the respective Request message. This allows the
Requester to correlate the Response to the original Request. The
Transaction Identifier is not used in ANCP adjacency messages. Also,
other ANCP applications not requiring it SHOULD set the Transaction
Identifier to 0x0 in their messages.
All TLVs within the ANCP message have to be 32 bit aligned, and when
necessary padded with 0s to the 32 bit boundary. The padding is not
reflected in the message length field.
5.4.5.1. General well known TLVs
This section contains the definitions of three general well known
TLVs. These TLVs are intended to be re-usable across different
Multicast messages.
5.4.5.1.1. Target TLV
The Target TLV (0x10) is intended to be a general well known TLV
allowing the representation of different types of objects. Its use
is not restricted to any specific Message Type.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Info ~
| |
Wadhwa, et al. Expires September 10, 2009 [Page 42]
Internet-Draft ancp protocol March 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target TLV:
TLV (0x10) indicating the type of target being addressed.
Numbers TBC. Tentative 0x1000 for single Access-Port.
Target TLV Length:
Length in bytes of Target Info. Excludes TLV header
Target Info:
Target information as defined for each the given target.
The field can consist of sub-TLVs.
In its simplest form, when targeting a single access line the Target-
TLV will be set to a value of (0x10), and carry in its payload one or
more sub-TLVs identifying the target. The following example
illustrates the message format for a single port identified by an
Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a
Port-UP message:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5.1.2. Command TLV
The Command TLV (0x11) is intended to be a general well known TLV
allowing the encapsulation of one or more command directives in a TLV
oriented message. The semantics of the command are allowed to be
specified for each message type, ie different message types that
choose to carry the Command TLV are expected to define the meaning of
the content of the payload, which could be re-used from those already
defined elsewhere if appropriate.
Wadhwa, et al. Expires September 10, 2009 [Page 43]
Internet-Draft ancp protocol March 2009
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 = Command | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Command Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional sub-TLV Type | Additional sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Additional sub-TLV data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Command TLV:
TLV (0x11) indicating the contents to be one or more
command directives.
Command TLV Length:
Combined length in bytes of the data in Command Info and
sub-TLV. Excludes the Command TLV header
Commad-Info:
Command information as defined for each message type. The
field can consist of sub-TLVs.
Additional sub-TLV:
Additional sub-TLVs can be present in a command TLV. Any
such sub-TLVs must directly follow each command.
Additional sub-TLV Length:
Number of actual bytes contained in the value portion of
each additional sub-TLV
5.4.5.1.3. Status-Info TLV
The Status-info-TLV is intended to be a general well known TLV used
to convey the status code regarding commands and/or requests. The
format of the Status-Info-TLV (0x012) is shown below.
Wadhwa, et al. Expires September 10, 2009 [Page 44]
Internet-Draft ancp protocol March 2009
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 = Status-info | Status TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmnd Nmbr | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (aligned to 4 bytes length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Status-info TLV:
TLV (0x12) conveying the status or error response of a
command
Status TLV Length:
Specifies the length in bytes of the Status Info TLV
payload. Excludes the TLV header
Result Code:
Conveys the result code for the command or message, as
defined by the application.
Cmnd Nmbr:
Contains the command number copied from the Request
message. The value of 0 is used whenever the error is not
specific to a command.
Error Message Length:
Contains the length of an optional error message or 0 if
none.
TLVs:
This field is of indeterminate length, and contains zero or
more of the TLVs associated with the Status-info-TLV.
5.4.5.2. Multicast Replication Control Message
The Multicast Replication Control Message Type 0x90 (TBC) is sent by
the NAS to the AN with a directive to either add (join) or delete
(leave) one or more multicast flows on a target object identified in
the content of the message. When a response is needed an AN MUST use
Wadhwa, et al. Expires September 10, 2009 [Page 45]
Internet-Draft ancp protocol March 2009
the Multicast Status message to convey the outcome of the directive;
this message type is covered in Section 5.4.5.3.
The sender of a Multicast Replication Control message MUST set the
Result field to 0x00 meaning "Ignore". The sender MUST populate the
ANCP Transaction Identifier field with a distinct non-zero, linearly
incrementing value for each Request per adjacency, as described in
Section 5.4.5 .
The ANCP Multicast Replication Control message payload contains the
following TLVs:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Target TLV | Length of Target-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value = Target-Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Length of Command Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value = Command Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target:
See Section 5.4.5.1.1. The Target TLV (0x10) can only feature
once in a Multicast Replication Control Message. Only one such
TLV is allowed in this message type.
Length of Target-Info:
See Section 5.4.5.1.1
Target Info:
See Section 5.4.5.1.1
Command TLV:
The Command TLV (0x11) contains the multicast flow
directive(s) for the target and any additional parameters
passed via sub-TLVs. See Section 5.4.5.1.2
Length of Command Info:
Wadhwa, et al. Expires September 10, 2009 [Page 46]
Internet-Draft ancp protocol March 2009
Includes sub-TLVs. See Section 5.4.5.1.2
Command Info:
Command information as defined in section
Section 5.4.5.1.2.
The contents of the Command TLV for the Multicast Replication Control
Message are defined to be as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |R O M Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++|
| Addr Family | Encoding Type | Multicast Flow Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++-+
Command Code:
Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
All.
Command Length:
Length in bytes of each Command including multicast flow
address, but excluding the Command Code header and flags.
Flags:
8 bit General purpose Flag field. Currently the following
flags are defined:
R -
Resource Admitted Flag. Set to 1 in an add
command to indicate that the flow resources have
been reserved by admission control, 0 otherwise.
Not used in delete command.
Wadhwa, et al. Expires September 10, 2009 [Page 47]
Internet-Draft ancp protocol March 2009
O -
Flow Accounting. When set in add command
indicates that byte accounting for the flow is to
commence.
M -
When set indicates that multicast flow is SSM and
the address-family-element set MUST specify the
source and group addresses. When not set
indicates that multicast flow is ASM and address-
family-element MUST specify the group address,
and the Source Address field is to be omitted.
Address Family:
The address family used
The unicast source address/mask follows the format defined in
[IANAAEA]
Encoded-Unicast-address: Takes the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
Encoded-Unicast-address: Takes the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
Encoding Type:
Wadhwa, et al. Expires September 10, 2009 [Page 48]
Internet-Draft ancp protocol March 2009
The type of encoding used within a specific Address Family.
The value `0' is reserved for this field, and represents
the native encoding of the Address Family.
The address as represented by the given Address Family and
Encoding Type.
Address:
The address as represented by the given Address Family and
Encoding Type.
The padding will be done after both addresses so that it is 32-bit
aligned. As an example for IPv4:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmdCode=0x01 |0 0 1 Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 0x1| Enc Type 0x0 | Src Address first 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address last 2 bytes | AddrFamily 0x1| Enc Type 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above example, no padding is required.
A received Multicast Replication Control Message containing an
unrecognized Target TLV MUST be communicated to the sender as an
error in a Multicast Status Message indicating the "Unrecognised port
Type - 0x04" error. The reception of a Multicast Replication Control
Message, or any ANCP message, that is found to have mandatory TLVs
missing is to be addressed as part of a ANCP base protocol mechanism
yet to be defined.
Each Multicast Replication Control Message may contain one or more
command directives, each encapsulated by their own Command TLVs. The
sender MUST use separate Command TLVs for each distinct multicast
flow. When successive commands relate to a given Target and flow,
the state of features controlled or affected by flags as well as by
optional attributes received in the Multicast Replication Control
message, are to be interpreted as replacing any such previous state
for that port and flow. As an example, successive Multicast
Replication Control messages containing add commands for a given port
Wadhwa, et al. Expires September 10, 2009 [Page 49]
Internet-Draft ancp protocol March 2009
and flow, but differing in the accounting flag setting should be
interpreted as affecting the state of the accounting feature.
The recipient of a Multicast Replication Control message is to run an
implicit directive numbering across the multiple directives in the
message. The numbering is to start from 0x01 for each directive in a
given ANCP Multicast Replication Control message, and be restarted
for subsequent messages. The recipient MUST process the directives
in the order of reception, and use the derived directive number in
any response messages, besides the Transaction ID.
The processing/execution of multiple directives contained in a single
Multicast Control message MUST be interrupted at the first error, and
the remaining commands in the Multicast Replication Control message
discarded. In such a case a Multicast Status message MUST be sent
indicating the command number that resulted in the error along with
the error code.
When the strict sequenced processing of the directives in a single
Multicast Control message is not required the directives MUST be
distributed across separate Multicast Replication Control messages.
Each command directive is equipped with an 8-bit Flags field that
allows specification of Multicast ASM or SSM modes of operation, and
an indication of other features or conditions attached to this
command (e.g. To enable accounting for the flow, etc). Unassigned
flags are reserved for future use, and could in the future be subject
of the capability negotiation. When receiving a Multicast
Replication Control Message containing an unrecognized Flag set (to
1), a recipient MUST interpret it as an error, and generate an
Multicast Status message indicating the error.
The multicast flow subject to the command is specified by means of
one or two well known Address Family designators ([IANAAEA]), the
IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02). When
the M flag is set the two Address-Family tuples MUST be present in
the strict order specifying the multicast flow source and group
respectively. When the M flag is cleared only one Address-Family is
allowed, specifying the multicast flow.
For future extensibility, each command may also have additional TLVs
appended following the command and multicast flow information
(referred to as "TLVs" in the message format above). Unrecognized
TLVs SHOULD be silently discarded. The figure below is an example of
a Multicast Replication Control message that would result in a swap
from multicast SSM flows 192.0.2.1, 233.252.0.2, to 192.0.2.2,
233.252.0.3 on the Target identified by the "Access Loop Circuit ID":
Wadhwa, et al. Expires September 10, 2009 [Page 50]
Internet-Draft ancp protocol March 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x02 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.0.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Command-TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow: 233.252.0.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5.3. Multicast Status Message
The Multicast Status Message (Message Type 0x91 - TBC) is sent by the
AN to the NAS in response to a Multicast Replication Control Message
and its command directives. A Multicast Status message MUST use the
same ANCP Transaction ID as that in the original Multicast
Replication Control Message. The Success or Failure status is
reported in the Result field of the ANCP header as described in
Section 5.4.5.
A Multicast Status Message indicating Success SHOULD simply consist
Wadhwa, et al. Expires September 10, 2009 [Page 51]
Internet-Draft ancp protocol March 2009
only of the base ANCP header with no body, however the message MAY
contain one or more TLVs that are meant to communicate any relevant
information to an application. The payload of a Multicast Status
Message indicating Failure MUST contain an Status-Info TLV (0x12), as
defined in Section 5.4.5.1.3, as its first TLV and SHOULD be followed
by the Target TLV and Port-info. Other TLVs MAY be present. A
Multicast Status message indicating Failure MUST be sent whenever a
Multicast Control message cannot be fulfilled or results in an
execution error. The Cmnd Nmbr parameter in the Status-Info TLV
contained by the Multicast Status Message is to indicate the number
of the command in the Multicast Replication Control Message that
resulted in an error.
0x00 - Success
0x01 - Malformed message
0x02 - Command not supported
0x03 - Flag set but not supported
0x04 - Unrecognized Target
0x05 - Unsupported Address Family
0x06 - Malformed flow address
0x07 - No resources
0x08 - Unknown Target
0x09 - Target down
0x0a - Configuration error (such as Port not enabled for
multicast)
0x0b - Multicast flow does not exist
0x0c - Unsupported address encoding
0x0d - Additional info needed to execute command (payload MAY
contain an indication of the expected info)
0x0e - Multicast flow count exceeded
Wadhwa, et al. Expires September 10, 2009 [Page 52]
Internet-Draft ancp protocol March 2009
0x0f - M Flag set, but no IP Source address provided
0x10 - Transaction-id out of sequence
An example of a failure message for an invalid address, including the
Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV
padding, is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x4 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=0x12 | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmd Number | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| Target TLV=0x10 | Target-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop ID type | Access-Loop ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. ATM-specific considerations
The 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
local significance on the NAS. The ANCP messages for topology
discovery and line configuration carry opaque "Access loop
Circuit-ID" which has only local significance on the DSLAMs.
The access loop circuit identifier can be carried as an ASCII string
in the ANCP messages. This allows ANCP to be decoupled from the
specifics of the underlying access technology being controlled. On
Wadhwa, et al. Expires September 10, 2009 [Page 53]
Internet-Draft ancp protocol March 2009
the other hand, this requires a NAS mechanism by which such
identifier can be correlated to the context of an "aggregation
network" facing IP interface (corresponding to the subscriber) on the
NAS. This would typically require local configuration of such IP
interfaces, or of the underlying ATM interfaces.
5.6. Ethernet-specific considerations
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 could use an "outer" VLAN to create a form
of "virtual path" between a given DSLAM and a given NAS. And then
use "inner" VLAN tags to create a form of "virtual circuit" on a per
DSL line basis. In this case, VLAN tags conveyed in topology
discovery and line configuration messages will allow to uniquely
identify the DSL line in a straightforward manner, assuming the VLAN
tags are not translated in some way by the aggregation network, and
are unique across physical ports.
However, some carriers do not wish to use this "connection oriented"
approach. Therefore, an alternative model is to bridge sessions from
multiple subscribers behind a DSLAM to a single VLAN in the
aggregation network. This is the N:1 model. In this model, or in
the case where user traffic is sent untagged, the access node needs
to insert the exact identity of the DSL line in the topology
discovery and line configuration messages, and then hve a mechanism
by which this can be correlated to the context of an "aggregation
network" facing IP interface (for the subscriber) on the NAS. This
can either be based on local configuration on the NAS, or on the fact
that such DSLAM (access node) typically inserts the "Access Loop
Circuit ID" in subscriber signaling messages relayed to the NAS (i.e.
DHCP or PPPoE discovery messages).
Section Section 5.4.1 defines "Access Loop Circuit ID".
6. IANA Considerations
This document defines the following additions to the GSMPv3 Message
Type Name Space registry:
+-------------------------------+--------+---------------+
| Message | Number | Reference |
+-------------------------------+--------+---------------+
| Multicast Replication Control | 90 | This document |
| Multicast Status | 91 | This document |
+-------------------------------+--------+---------------+
Wadhwa, et al. Expires September 10, 2009 [Page 54]
Internet-Draft ancp protocol March 2009
This document defines the following modification to the Global Switch
Management Protocol version 3 (GSMPv3) Result Type Name Space
registry:
+--------------+------------------------+---------------+
| Result Value | Result Type Name | Reference |
+--------------+------------------------+---------------+
| 0 | Ignore (from Reserved) | This document |
+--------------+------------------------+---------------+
This document defines the following addition to the GSMPv3 Message
Function Name Space registry [editor's note GMSPv3 did not define a
Name Space for Function even if RFC3292 defines values for function
field]:
+----------------+-----------------+---------------+
| Function Value | Function Name | Reference |
+----------------+-----------------+---------------+
| 0x09 | Remote loopback | This document |
+----------------+-----------------+---------------+
This document reserves the range 0x500 to 0x5ff of GSMPv3 Failure
Response Message Name Space registry to indicate the status of the
executed test for OAM use case described in Section 5.4.4. The
initial entries are as follows:
+-------------------------+----------------------------+------------+
| Failure Response | Failure Response Message | Reference |
| Message Value | Name | |
+-------------------------+----------------------------+------------+
| 0x500 | Specified access line does | This |
| | not exist | document |
| 0x501 | Loopback test timed out | This |
| | | document |
| 0x502 | Reserved | This |
| | | document |
| 0x503 | DSL line status showtime | This |
| | | document |
| 0x0504 | DSL line status idle | This |
| | | document |
| 0x0505 | DSL line status silent | This |
| | | document |
| 0x0506 | DSL line status training | This |
| | | document |
| 0x507 | DSL line integrity error | This |
| | | document |
| 0x0508 | DSLAM resource not | This |
| | available | document |
Wadhwa, et al. Expires September 10, 2009 [Page 55]
Internet-Draft ancp protocol March 2009
| 0x509 | Invalid test parameter | This |
| | | document |
+-------------------------+----------------------------+------------+
This document defines a new ANCP Tech Type Name Space registry. The
initial entries are as follows:
+----------------+-----------------------------------+--------------+
| Tech Type | Tech Type Name | Reference |
| Value | | |
+----------------+-----------------------------------+--------------+
| 0x00 | Extension block not in use | This |
| | | document |
| 0x01 - 0x04 | Already in use by various | This |
| | technologies | document |
| 0x05 | DSL | This |
| | | document |
| 0x06 - 0xFE | Reserved | This |
| | | document |
| 0xFF | Base Specification Use | This |
| | | document |
+----------------+-----------------------------------+--------------+
This document defines a new ANCP Status-Info Result Code registry.
The initial entries are as follows:
+-----------------------------------------------+-------+-----------+
| Result Code | Value | Reference |
+-----------------------------------------------+-------+-----------+
| Success | 0x00 | This |
| | | document |
| Malformed message | 0x01 | This |
| | | document |
| Command not supported | 0x02 | This |
| | | document |
| Flag set but not supported | 0x03 | This |
| | | document |
| Unrecognized Target | 0x04 | This |
| | | document |
| Unsupported Address Family | 0x05 | This |
| | | document |
| Malformed flow address | 0x06 | This |
| | | document |
| No resources | 0x07 | This |
| | | document |
| Unknown Target | 0x08 | This |
| | | document |
Wadhwa, et al. Expires September 10, 2009 [Page 56]
Internet-Draft ancp protocol March 2009
| Target down | 0x09 | This |
| | | document |
| Configuration error (such as Port not enabled | 0x0a | This |
| for multicast) | | document |
| Multicast flow does not exist | 0x0b | This |
| | | document |
| Unsupported address encoding | 0x0c | This |
| | | document |
| Additional info needed to execute command | 0x0d | This |
| (payload MAY contain an indication of the | | document |
| expected info) | | |
| Multicast flow count exceeded | 0x0e | This |
| | | document |
| M Flag set, but no IP Source address provided | 0x0f | This |
| | | document |
| Transaction-id out of sequence | 0x010 | This |
| | | document |
+-----------------------------------------------+-------+-----------+
This document defines a new ANCP Command Code registry. The initial
entries are as follows:
+-----------------------------+--------------------+---------------+
| Command Code Directive Name | Command Code Value | Reference |
+-----------------------------+--------------------+---------------+
| Reserved | 0x00 | This document |
| Add | 0x01 | This document |
| Delete | 0x02 | This document |
| Delete All | 0x03 | This document |
+-----------------------------+--------------------+---------------+
This document defines a new ANCP TLV Type registry. The initial
entries are as follows:
Wadhwa, et al. Expires September 10, 2009 [Page 57]
Internet-Draft ancp protocol March 2009
+--------------------------------------+-----------+---------------+
| TLV Name | Type Code | Reference |
+--------------------------------------+-----------+---------------+
| Access-Loop-Circuit-ID | 0x01 | This document |
| Access-Loop-Remote-Id | 0x02 | This document |
| Access-Aggregation-Circuit-ID-ASCII | 0x03 | This document |
| DSL Line Attributes | 0x04 | This document |
| Service-Profile-Name | 0x05 | This document |
| Access-Aggregation-Circuit-ID-Binary | 0x06 | This document |
| OAM-Loopback-Test-Parameters | 0x07 | This document |
| Opaque-Data | 0x08 | This document |
| OAM-Loopback-Test-Response-String | 0x09 | This document |
| Reserved | 0x0a-0x0f | This document |
| Target | 0x10 | This document |
| Command | 0x11 | This document |
| Status-Info | 0x012 | This document |
+--------------------------------------+-----------+---------------+
This document defines a new ANCP Capability registry. The initial
entries are as follows:
+----------------------------+----------------------+---------------+
| Capability Type Name | Capability Type Code | Reference |
+----------------------------+----------------------+---------------+
| Dynamic-Topology-Discovery | 0x01 | This document |
| Line-Configuration | 0x02 | This document |
| Transactional-Multicast | 0x03 | This document |
| OAM | 0x04 | This document |
+----------------------------+----------------------+---------------+
This document defines a new ANCP sub-TLV Type registry. The initial
entries are as follows:
Wadhwa, et al. Expires September 10, 2009 [Page 58]
Internet-Draft ancp protocol March 2009
+--------------------------------------------+--------+-------------+
| sub-TLV Name | Type | Reference |
| | Code | |
+--------------------------------------------+--------+-------------+
| Actual-Net-Data-Upstream | 0x81 | This |
| | | document |
| Actual-Net-Data-Rate-Downstream | 0x82 | This |
| | | document |
| Minimum-Net-Data-Rate-Upstream | 0x83 | This |
| | | document |
| Minimum-Net-Data-Rate-Downstream | 0x84 | This |
| | | document |
| Attainable-Net-Data-Rate-Upstream | 0x85 | This |
| | | document |
| Attainable-Net-Data-Rate-Downstream | 0x86 | This |
| | | document |
| Maximum-Net-Data-Rate-Upstream | 0x87 | This |
| | | document |
| Maximum-Net-Data-Rate-Downstream | 0x88 | This |
| | | document |
| Minimum-Net-Low-Power-Data-Rate-Upstream | 0x89 | This |
| | | document |
| Minimum-Net-Low-Power-Data-Rate-Downstream | 0x8A | This |
| | | document |
| Maximum-Interleaving-Delay-Upstream | 0x8B | This |
| | | document |
| Actual-Interleaving-Delay-Upstream | 0x8C | This |
| | | document |
| Maximum-Interleaving-Delay-Downstream | 0x8D | This |
| | | document |
| Actual-Interleaving-Delay-Downstream | 0x8E | This |
| | | document |
| DSL line state | 0x8F | This |
| | | document |
| Access Loop Encapsulation | 0x90 | This |
| | | document |
| DSL-Type | 0x91 | This |
| | | document |
+--------------------------------------------+--------+-------------+
7. Security Considerations
Security of the ANCP protocol is discussed in [ANCP-SEC]
Wadhwa, et al. Expires September 10, 2009 [Page 59]
Internet-Draft ancp protocol March 2009
8. Acknowledgements
The authors would like to thank everyone that has provided comments
or inputs to this document. In particular, the authors acknowledge
the inputs provided by Peter Arberg, Josef Froehler, Derek Harkness,
Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic, Tom Taylor
and the work done by Philippe Champagne, Wojciech Dec and Stefaan De
Cnodder regarding multicast extensions.
9. References
9.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",
January 2001.
[RFC3292] Doria, A. and et all, "General Switch Management Protocol
(GSMP) V3", June 2002.
[RFC3293] Worster, T., Doria, A., and and J. Buerkle, "General
Switch Management Protocol (GSMP) Packet Encapsulations
for Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", June 2002.
9.2. Informative References
[ANCP-FRAMEWORK]
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-08.txt, , February 2009.
[ANCP-SEC]
Moustafa, H., Tschofenig, T., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node
Control Protocol (ANCP)",
draft-ietf-ancp-security-threats-07.txt work in progress,
March 2009.
[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.
Wadhwa, et al. Expires September 10, 2009 [Page 60]
Internet-Draft ancp protocol March 2009
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers",
2005.
[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.
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 September 10, 2009 [Page 61]
Internet-Draft ancp protocol March 2009
Swami Subramanian
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Phone:
Fax:
Email: ssubramanian@juniper.net
Thomas Haag
T-systems
Phone:
Fax:
Email: thomas.haag@t-systems.com
Norber Voigt
Siemens
Phone:
Fax:
Email: norbert.voigt@siemens.com
Roberta Maglione
Telecom Italia
via Reiss Romoli 274
Torino
Italy
Phone:
Email: roberta.maglione@telecomitalia.it
Wadhwa, et al. Expires September 10, 2009 [Page 62]
