draft-ietf-ancp-protocol-00.txt   draft-ietf-ancp-protocol-01.txt 
Working Group Name Sanjay Wadhwa Working Group Name Sanjay Wadhwa
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expires: August 25, 2007 Expires: January 9, 2008
Jerome Moisand Jerome Moisand
Juniper Networks Juniper Networks
Swami Subramanian Swami Subramanian
Juniper Networks Juniper Networks
Thomas Haag Thomas Haag
T-Systems T-Systems
Norbert Voigt Norbert Voigt
Siemens Siemens
February 25, 2007 July 9, 2007
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-00.txt draft-ietf-ancp-protocol-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with section 6 of BCP 79. aware will be disclosed, in accordance with section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 45 skipping to change at page 1, line 45
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 22, 2007. This Internet-Draft will expire on Jan 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). All Rights Reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes proposed extensions to the GSMPv3 protocol to This document describes proposed extensions to the GSMPv3 protocol to
allow its use in a broadband environment, as a control plane between allow its use in a broadband environment, as a control plane between
Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS).
These proposed extensions are required to realize a protocol for These proposed extensions are required to realize a protocol for
“Access Node Control” mechanism as described in [9]. The resulting “Access Node Control” mechanism as described in [8]. The resulting
protocol with the proposed extensions to GSMPv3 [4] is referred to as protocol with the proposed extensions to GSMPv3 [4] is referred to as
“Access Node Control Protocol” (ANCP). This document focuses on “Access Node Control Protocol” (ANCP). This document currently
specific use cases of access node control mechanism for topology focuses on specific use cases of access node control mechanism for
discovery, line configuration, and OAM. It is intended to be topology discovery, line configuration, and OAM as described in ANCP
augmented by additional protocol specification for future use cases framework document [8]. It is intended to be augmented by additional
considered in scope by the ANCP charter. protocol specification for future use cases considered in scope by
the ANCP charter.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", ANCP framework document [8] describes the ANCP use-cases in detail.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Illustrative text for the use-cases is included here to help the
document are to be interpreted as described in RFC-2119 [1]. protocol implementer understand the greater context of ANCP protocol
interactions.
Table of Contents Table of Contents
1 Specification Requirements 4 1 Specification Requirements 4
2 Introduction4 2 Introduction4
3 Broadband Access Aggregation 4 3 Broadband Access Aggregation 5
3.1 ATM-based broadband aggregation..........................4 3.1 ATM-based broadband aggregation..........................5
3.2 Ethernet-based broadband aggregation.....................6 3.2 Ethernet-based broadband aggregation.....................6
4 Access Node Control Protocol 7 4 Access Node Control Protocol 7
4.1 Overview.................................................7 4.1 Overview.................................................7
4.2 ANCP based Access Topology Discovery.....................8 4.2 ANCP based Access Topology Discovery.....................8
4.2.1 Goals..............................................8 4.2.1 Goals..............................................8
4.2.2 Message Flow.......................................8 4.2.2 Message Flow.......................................8
4.3 ANCP based Line Configuration............................9 4.3 ANCP based Line Configuration............................9
4.3.1 Goals..............................................9 4.3.1 Goals..............................................9
4.3.2 Message Flow......................................10 4.3.2 Message Flow......................................10
4.4 ANCP based Transactional Multicast......................12 4.4 ANCP based Transactional Multicast......................12
skipping to change at page 3, line 5 skipping to change at page 2, line 51
4.1 Overview.................................................7 4.1 Overview.................................................7
4.2 ANCP based Access Topology Discovery.....................8 4.2 ANCP based Access Topology Discovery.....................8
4.2.1 Goals..............................................8 4.2.1 Goals..............................................8
4.2.2 Message Flow.......................................8 4.2.2 Message Flow.......................................8
4.3 ANCP based Line Configuration............................9 4.3 ANCP based Line Configuration............................9
4.3.1 Goals..............................................9 4.3.1 Goals..............................................9
4.3.2 Message Flow......................................10 4.3.2 Message Flow......................................10
4.4 ANCP based Transactional Multicast......................12 4.4 ANCP based Transactional Multicast......................12
4.5 ANCP based OAM..........................................13 4.5 ANCP based OAM..........................................13
4.5.1 Message Flow......................................13 4.5.1 Message Flow......................................13
5 Access Node Control Protocol (ANCP) 14 5 Access Node Control Protocol (ANCP) 14
5.1 ANCP/TCP connection establishment.......................16
5.2 ANCP Connection keep-alive..............................16
5.3 Capability negotiation..................................17
5.4 GSMP Message Extensions for Access Node Control.........20
5.4.1 General Extensions................................20
5.4.2 Topology Discovery Extensions.....................23
5.4.3 Line Configuration Extensions.....................32
5.4.4 OAM Extensions....................................34
5.5 ATM-specific considerations.............................37
5.6 Ethernet-specific considerations........................38
6 IANA Considerations 38
5.1 ANCP/TCP connection establishment.......................14 7 Security Considerations 38
5.2 ANCP Connection keep-alive..............................15
5.3 Capability negotiation..................................16
5.4 GSMP Message Extensions for Access Node Control.........18
5.4.1 General Extensions................................18
5.4.2 Topology Discovery Extensions.....................21
5.4.3 Line Configuration Extensions.....................30
5.4.4 OAM Extensions....................................32
5.5 ATM-specific considerations.............................35
5.6 Ethernet-specific considerations........................36
6 IANA Considerations 36
7 Security Considerations 36
8 References 37 8 References 39
Author's Addresses38 Author's Addresses 40
Intellectual Property Statement 38 Full Copyright Statement 40
Disclaimer of Validity 39 Copyright (C) The IETF Trust (2007). 40
Copyright Statement 39 Intellectual Property 41
Acknowledgment 39 Acknowledgment 41
1 Specification Requirements 1 Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
“SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT",“SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
2 Introduction 2 Introduction
DSL is a widely deployed access technology for Broadband Access for DSL is a widely deployed access technology for Broadband Access for
Next Generation Networks. Several specifications like [1-3] describe Next Generation Networks. Several specifications like [1-3] describe
possible architectures for these access networks. In the scope of possible architectures for these access networks. In the scope of
these specifications are the delivery of voice, video and data these specifications are the delivery of voice, video and data
services. services.
When deploying value-added services across DSL access networks, When deploying value-added services across DSL access networks,
skipping to change at page 4, line 32 skipping to change at page 4, line 32
layer. layer.
This draft defines extensions and modifications to GSMPv3 (specified This draft defines extensions and modifications to GSMPv3 (specified
in [4]) and certain new mechanisms to realize a control plane between in [4]) and certain new mechanisms to realize a control plane between
a service-oriented layer 3 edge device (the NAS) and a layer2 Access 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 Node (e.g. DSLAM) in order to perform QoS-related, service-related
and subscriber-related operations. The control protocol as a result and subscriber-related operations. The control protocol as a result
of these extensions and mechanisms is referred to as “Access Node of these extensions and mechanisms is referred to as “Access Node
Control Protocol” (ANCP). Control Protocol” (ANCP).
In addition to specifying extensions and modifications to relevant ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP
GSMP messages applicable to access node control mechanism, this draft encapsulation for GSMPv3 is defined in [5]. GSMPv3 encapsulation
also defines values that ANCP should set for relevant fields in these directly over Ethernet and ATM as defined in [5] is not considered
GSMP messages. However, to understand the basic semantics of various for ANCP.
ANCP uses a subset of GSMPv3 messages to implement currently defined
use-cases. These relevant GSMPv3 messages are identified in section
5. GSMPv3 procedures with suitable extensions, as used by ANCP, are
described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and
GSMPv3 message specific extensions required by ANCP are described in
sub-sections of 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, and indicates
the values that ANCP should set for relevant fields in these GSMP
messages. However, to understand the basic semantics of various
fields in GSMP messages, the reader is referred to [4]. fields in GSMP messages, the reader is referred to [4].
3 Broadband Access Aggregation 3 Broadband Access Aggregation
3.1 ATM-based broadband aggregation 3.1 ATM-based broadband aggregation
End to end DSL network consists of network and application service End to end DSL network consists of network and application service
provider networks (NSP and ASP networks), regional/access network, provider networks (NSP and ASP networks), regional/access network,
and customer premises network. Fig1. shows ATM broadband access and customer premises network. Fig1. shows ATM broadband access
network components. network components.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
management and IP QoS in the Regional/Access Networks. In order to 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 allow IP QoS support over an existing non-IP-aware layer 2 access
network without using multiple layer 2 QoS classes, a mechanism based network without using multiple layer 2 QoS classes, a mechanism based
on hierarchical scheduling is used. This mechanism defined in [1], on hierarchical scheduling is used. This mechanism defined in [1],
preserves IP QoS over the ATM network between the NAS and the RGs by preserves IP QoS over the ATM network between the NAS and the RGs by
carefully controlling downstream traffic in the NAS, so that carefully controlling downstream traffic in the NAS, so that
significant queuing and congestion does not occur further down the significant queuing and congestion does not occur further down the
ATM network. This is achieved by using a diffserv-aware hierarchical ATM network. This is achieved by using a diffserv-aware hierarchical
scheduler in the NAS that will account for downstream trunk scheduler in the NAS that will account for downstream trunk
bandwidths and DSL synch rates. bandwidths and DSL synch rates.
[9] provides detailed definition and functions of each network [8] provides detailed definition and functions of each network
element in the broadband reference architecture. element in the broadband reference architecture.
Access Customer Access Customer
<--- Aggregation ---> <------- Premises -------> <--- Aggregation ---> <------- Premises ------->
Network Network Network Network
+-------------------+ +--------------------------+ +-------------------+ +--------------------------+
+----------+ +-----+ | +-----+ +------+ |--|+-----+ +--+ +----------+ | +----------+ +-----+ | +-----+ +------+ |--|+-----+ +--+ +----------+ |
| | +-|NAS |---| |ATM |--|Access| | ||DSL |-|RG|-|Subscriber| | | | +-|NAS |---| |ATM |--|Access| | ||DSL |-|RG|-|Subscriber| |
NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +--+ |Devices | | NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +--+ |Devices | |
skipping to change at page 7, line 6 skipping to change at page 7, line 6
802.ad. 802.ad.
Stacked VLAN tags provide one possible way to create equivalent of Stacked VLAN tags provide one possible way to create equivalent of
“virtual paths” and “virtual circuits” in the aggregation network. The “virtual paths” and “virtual circuits” in the aggregation network. The
“outer” vlan could be used to create a form of “virtual path” between a “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 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 “virtual circuit” on a per DSL line basis. This is 1:1 VLAN allocation
model. An alternative model is to bridge sessions from multiple model. An alternative model is to bridge sessions from multiple
subscribers behind a DSLAM into a single VLAN in the aggregation subscribers behind a DSLAM into a single VLAN in the aggregation
network. This is N:1 VLAN allocation model. Architectural and network. This is N:1 VLAN allocation model. Architectural and
topological models of an Ethernet aggregation network in context of DSL topological models of an Ethernet aggregation network in context of DSL
aggregation are defined in [8]. aggregation are defined in [7].
4 Access Node Control Protocol 4 Access Node Control Protocol
4.1 Overview 4.1 Overview
A dedicated control protocol between NAS and access nodes can A dedicated control protocol between NAS and access nodes can
facilitate "NAS managed" tight QOS control in the access network, facilitate "NAS managed" tight QOS control in the access network,
simplified OSS infrastructure for service management, optimized simplified OSS infrastructure for service management, optimized
multicast replication to enable video services over DSL, subscriber multicast replication to enable video services over DSL, subscriber
statistics retrieval on the NAS for accounting purposes, and fault statistics retrieval on the NAS for accounting purposes, and fault
skipping to change at page 14, line 21 skipping to change at page 14, line 21
|Radius/AAA |------|NAS |---------| DSLAM |-------------| CPE | |Radius/AAA |------|NAS |---------| DSLAM |-------------| CPE |
|Policy Server| +-----+ +-------+ | (DSL Modem + | |Policy Server| +-----+ +-------+ | (DSL Modem + |
+-------------+ | Routing Gateway)| +-------------+ | Routing Gateway)|
+-----------------+ +-----------------+
3. <--------------- 3. <---------------
Port Management Message Port Management Message
(Remote Loopback Test Response) (Remote Loopback Test Response)
5 Access Node Control Protocol (ANCP) 5 Access Node Control Protocol (ANCP)
ANCP uses a subset of GSMPv3 messages described in [4] 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 RFC [4]. ANCP modifies this base GSMPv3
message format. The modified GSMPv3 message format is defined 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. The definition and semantics of all the fields in the
header are described in section 3.1.1 of GSMPv3 RFC [4]. An ANCP
implementation SHOULD set the I and subMessage fields to 1 to signify
no fragmentation.
Following are the relevant GSMPv3 messages defined in [4], that are
currently used by ANCP. Other than the message types explicitly
listed below, no other GSMPv3 messages are used by ANCP currently.
o Event Messages
o Port UP message
o 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.
The basic format and semantics of various fields in these GSMPv3
messages identified above are described in GSMPv3 RFC [4]. However,
the usage of these messages by ANCP, along with relevant
modifications and extensions required by ANCP, are described in
sections 5.3, 5.4.1, 5.4.2 and 5.4.3 of this document. Messages used
by ANCP multicast use-case will be described in future versions of
this document.
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 5.3.
o TCP connection establishment procedure in ANCP deviates
slightly from the connection establishment in GSMPv3 as
specified in [5]. This is described in 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 5.4.1.1.
o ANCP extends GSMPv3 message exchange with a “bulk transaction”
capability, where multiple GSMPv3 messages can be bundled into
a single GSMPv3 transaction. This is described in section
5.4.1.2.
5.1 ANCP/TCP connection establishment 5.1 ANCP/TCP connection establishment
ANCP will use TCP for exchanging protocol messages. [5] defines the ANCP will use TCP for exchanging protocol messages. [5] defines the
GSMP message encapsulation for TCP. The TCP session is initiated GSMP message encapsulation for TCP. The TCP session is initiated
from the DSLAM (access node) to the NAS (controller). This is from the DSLAM (access node) to the NAS (controller). This is
necessary to avoid static provisioning on the NAS for all the DSLAMs 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 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. DSLAM with the single IP address of the NAS that serves the DSLAM.
This is a deviation from [5] which indicates that the controller This is a deviation from [5] which indicates that the controller
initiates the TCP connection to the switch. initiates the TCP connection to the switch.
skipping to change at page 23, line 32 skipping to change at page 25, line 32
Following TLVs are currently defined: Following TLVs are currently defined:
1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and 1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and
contains an identifier of the subscriber’s connection to the access contains an identifier of the subscriber’s connection to the access
node (i.e. “local loop”). The “local loop” can be ATM based or node (i.e. “local loop”). The “local loop” can be ATM based or
Ethernet based. The “Access Loop Circuit ID” has local significance Ethernet based. The “Access Loop Circuit ID” has local significance
at the access node. The exact usage on the NAS is beyond the scope at the access node. The exact usage on the NAS is beyond the scope
of this document. The format used for “local loop” identification of this document. The format used for “local loop” identification
in ANCP messages MUST be identical to what is used by the access in ANCP messages MUST be identical to what is used by the access
nodes in subscriber signaling messages when the access nodes act as nodes in subscriber signaling messages when the access nodes act as
“signaling relay agents” as outlined in [7] and [8]. “signaling relay agents” as outlined in [6] and [7].
Length : (upto 63 bytes) Length : (upto 63 bytes)
Value : ASCII string. Value : ASCII string.
For an ATM based local loop the string consists of slot/port and For an ATM based local loop the string consists of slot/port and
VPI/VCI information corresponding to the subscriber’s DSL VPI/VCI information corresponding to the subscriber’s DSL
connection. Default syntax for the string inserted by the access connection. Default syntax for the string inserted by the access
node as per [8] is: node as per [7] is:
“Access-Node-Identifier atm slot/port:vpi.vci” “Access-Node-Identifier atm slot/port:vpi.vci”
The Access-Node-Identifier uniquely identifies the access node in The Access-Node-Identifier uniquely identifies the access node in
the access network. The slot/port and VPI/VCI uniquely identifies the access network. The slot/port and VPI/VCI uniquely identifies
the DSL line on the access node. Also, there is one to one the DSL line on the access node. Also, there is one to one
correspondence between DSL line and the VC between the access node correspondence between DSL line and the VC between the access node
and the NAS. and the NAS.
For local loop which is Ethernet based (and tagged), the string For local loop which is Ethernet based (and tagged), the string
consists of slot/port and VLAN tag corresponding to the consists of slot/port and VLAN tag corresponding to the
subscriber. Default syntax for the string inserted by the access subscriber. Default syntax for the string inserted by the access
node as per [8] is: node as per [7] is:
"Access-Node-Identifier eth slot/port[:vlan-id]" "Access-Node-Identifier eth slot/port[:vlan-id]"
2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and 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 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 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 this document. It is desirable that the format used for the field
is similar to what is used by the access nodes in subscriber is similar to what is used by the access nodes in subscriber
signaling messages when the access nodes act as “signaling relay signaling messages when the access nodes act as “signaling relay
agents” as outlined in [7] and [8]. agents” as outlined in [6] and [7].
Length : (upto 63 bytes) Length : (upto 63 bytes)
Value : ASCII string Value : ASCII string
3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) 3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06)
Length : (8 bytes) Length : (8 bytes)
Value : two 32 bit integers. Value : two 32 bit integers.
For ethernet access aggregation, where a per-subscriber (stacked) For ethernet access aggregation, where a per-subscriber (stacked)
VLAN can be applied (1:1 model defined in [8]), the VLAN stack VLAN can be applied (1:1 model defined in [7]), the VLAN stack
provides a convenient way to uniquely identify the DSL line. The provides a convenient way to uniquely identify the DSL line. The
outer VLAN is equivalent to virtual path between a DSLAM and 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 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 line basis. In this scenario, any subscriber data received by the
access node and transmitted out the uplink to the aggregation access node and transmitted out the uplink to the aggregation
network will be tagged with the VLAN stack assigned by the access network will be tagged with the VLAN stack assigned by the access
node node
This TLV can carry the VLAN tags assigned by the access node in the 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 ANCP messages. The VLAN tags can uniquely identify the DSL line
skipping to change at page 32, line 7 skipping to change at page 34, line 7
including the padding if present). If a TLV is not understood by the including the padding if present). If a TLV is not understood by the
access-node, it is silently ignored. Depending upon the deployment access-node, it is silently ignored. Depending upon the deployment
scenario, the NAS may specify “Access Loop Circuit-ID” or the “Access scenario, the NAS may specify “Access Loop Circuit-ID” or the “Access
Aggregation Circuit-ID) as defined in section 5.4.1. Following TLVs Aggregation Circuit-ID) as defined in section 5.4.1. Following TLVs
can appear in this message: can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section 5.4.1.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
section 5.4.1. 5.4.1.
o Type (Service-Profile-Name = 0x05): Reference to a pre-configured o Type (Service-Profile-Name = 0x05): Reference to a pre-configured
profile on the DSLAM that contains service specific data for the profile on the DSLAM that contains service specific data for the
subscriber. subscriber.
Length : (upto 64 bytes) Length : (upto 64 bytes)
Value : ASCII string containing the profile name (NAS learns Value : ASCII string containing the profile name (NAS learns
from a policy server after a subscriber is authorized). from a policy server after a subscriber is authorized).
skipping to change at page 33, line 10 skipping to change at page 35, line 10
present). If a TLV is not understood by the NAS, it is silently present). If a TLV is not understood by the NAS, it is silently
ignored. Depending upon the deployment scenario, the NAS may specify ignored. Depending upon the deployment scenario, the NAS may specify
“Access Loop Circuit-ID” or the “Access Aggregation Circuit-ID) as “Access Loop Circuit-ID” or the “Access Aggregation Circuit-ID) as
defined in section 5.4.1. Following TLVs can appear in this message: defined in section 5.4.1. Following TLVs can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section 5.4.1.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
section 5.4.1. 5.4.1.
o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to
loopback test. This is an optional TLV. If this TLV is not present loopback test. This is an optional TLV. If this TLV is not present
in the request message, the DSLAM SHOULD use locally determined in the request message, the DSLAM SHOULD use locally determined
default values for the test parameters. default values for the test parameters.
Length: 4 bytes Length: 4 bytes
Value : two 1 byte numbers described below (listed in order of Value : two 1 byte numbers described below (listed in order of
most to least significant). Thus, the 4 bytes consist of 1 byte 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 Count, followed by 1 byte of Timeout, followed by two pad bytes
of zero. of zero.
o Count (1 byte) : Number of loopback cells/messages that should o Count (1 byte) : Number of loopback cells/messages that should
be generated on the local loop as part of the loopback test. be generated on the local loop as part of the loopback test.
The NAS SHOULD restrict the “count” to be greater than 0 and The NAS SHOULD restrict the “count” to be greater than 0 and
less than or equal to 32. The DSLAM SHOULD discard the request less than or equal to 32. The DSLAM SHOULD discard the request
for a loopback test, if the received test parameters contain for a loopback test, if the received test parameters contain an
an out of range value for the “count” field. The DSLAM MAY out of range value for the “count” field. The DSLAM MAY
optionally send a failure response to the NAS with the code optionally send a failure response to the NAS with the code
“invalid test parameter”. “invalid test parameter”.
o Timeout (1 byte) : Upper bound on the time in seconds that the o Timeout (1 byte) : Upper bound on the time in seconds that the
NAS would wait for a response from the DSLAM. If the total NAS would wait for a response from the DSLAM. If the total time
time taken by the DSLAM to complete a test with requested taken by the DSLAM to complete a test with requested
parameters, exceeds the specified “timeout” value, it can parameters, exceeds the specified “timeout” value, it can
choose to omit the generation of a response to the NAS. DSLAM choose to omit the generation of a response to the NAS. DSLAM
SHOULD use a locally determined value for the “timeout”, if SHOULD use a locally determined value for the “timeout”, if the
the received value of the “timeout” parameter is 0. received value of the “timeout” parameter is 0.
o Type (Opaque-Data = 0x08) : This is an optional TLV. If present in o Type (Opaque-Data = 0x08) : This is an optional TLV. If present in
the request message, the DSLAM SHOULD reflect it back in the the request message, the DSLAM SHOULD reflect it back in the
response unmodified. response unmodified.
Length : 8 bytes Length : 8 bytes
Value : Two 32 bit integers inserted by the NAS (not to be Value : Two 32 bit integers inserted by the NAS (not to be
interpreted by the DSLAM, but just reflected back in the interpreted by the DSLAM, but just reflected back in the
response). response).
skipping to change at page 34, line 49 skipping to change at page 36, line 49
The Extension value can contain one or more TLVs including the TLV to 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 identify the access line on which the test was performed, and details
from executing the test. The access line identifier SHOULD be identical from executing the test. The access line identifier SHOULD be identical
to what was contained in the request. The relevant TLVs are: to what was contained in the request. The relevant TLVs are:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1
o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in
section 5.4.1. section 5.4.1.
o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section
section 5.4.1. 5.4.1.
o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the request
request reflected back by the DSLAM. reflected back by the DSLAM.
Length : 8 bytes Length : 8 bytes
Value : Two 32 bit integers as received in the request (opaque to Value : Two 32 bit integers as received in the request (opaque to
the DSLAM). the DSLAM).
o Type (OAM-Loopback-Test-Response-String = 0x09) o Type (OAM-Loopback-Test-Response-String = 0x09)
Length (upto 128 bytes) Length (upto 128 bytes)
skipping to change at page 37, line 26 skipping to change at page 39, line 26
document. document.
[4] Doria, A. et al, "General Switch Management Protocol- V3" (GSMP [4] Doria, A. et al, "General Switch Management Protocol- V3" (GSMP
v3), RFC 3292, June 2002. v3), RFC 3292, June 2002.
[5] Worster, T., Doria, A. and J. Buerkle, "General Switch [5] Worster, T., Doria, A. and J. Buerkle, "General Switch
Management Protocol (GSMP) Packet Encapsulations for Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and Transmission Asynchronous Transfer Mode (ATM), Ethernet and Transmission
Control Protocol (TCP)", RFC 3293, June 2002. Control Protocol (TCP)", RFC 3293, June 2002.
[6] GSMP extensions for ANCP - Transactional Multicast, draft- [6] “DHCP Relay Agent Information Option”, RFC 3046, January 2001.
moisand-gsmp-ancp-multicast-00 (work in progress).
[7] “DHCP Relay Agent Information Option”, RFC 3046, January 2001.
[8] Architecture & Transport: Migration to Ethernet Based DSL [7] Architecture & Transport: Migration to Ethernet Based DSL
Aggregation, DSL Forum WT-101, Cohen et al. Aggregation, DSL Forum WT-101, Cohen et al.
[9] Framework for Access Node Control Mechanism in Broadband [8] Framework for Access Node Control Mechanism in Broadband
Networks, draft-ietf-ancp-framework-00.txt. Networks, draft-ietf-ancp-framework-00.txt.
Author's Addresses Author's Addresses
Sanjay Wadhwa Sanjay Wadhwa
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
Email: swadhwa@juniper.net Email: swadhwa@juniper.net
skipping to change at page 39, line ? skipping to change at page 40, line 44
Siemens Siemens
Email: norbert.voigt@siemens.com Email: norbert.voigt@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights. This document and the information contained
herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
This document and the information contained herein are provided on an ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED OR FITNESS FOR A PARTICULAR PURPOSE.
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 39, line ? skipping to change at page 41, line 33
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org
Acknowledgment Acknowledgment
Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim
Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic for their Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic for their
input to this document. input to this document.
 End of changes. 42 change blocks. 
83 lines changed or deleted 172 lines changed or added

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