draft-ietf-ancp-protocol-06.txt   draft-ietf-ancp-protocol-07.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft J. Moisand Internet-Draft J. Moisand
Intended status: Standards Track S. Subramanian Intended status: Standards Track S. Subramanian
Expires: January 14, 2010 Juniper Networks Expires: April 25, 2010 Juniper Networks
T. Haag T. Haag
T-systems T-systems
N. Voigt N. Voigt
Siemens Siemens
R. Maglione R. Maglione
Telecom Italia Telecom Italia
July 13, 2009 October 22, 2009
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-06 draft-ietf-ancp-protocol-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 January 14, 2010. This Internet-Draft will expire on April 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 10 skipping to change at page 3, line 10
ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases
in detail. Illustrative text for the use-cases is included here to in detail. Illustrative text for the use-cases is included here to
help the protocol implementer understand the greater context of ANCP help the protocol implementer understand the greater context of ANCP
protocol interactions. protocol interactions.
Table of Contents Table of Contents
1. Specification Requirements . . . . . . . . . . . . . . . . . . 4 1. Specification Requirements . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 5 3. Broadband Access Aggregation . . . . . . . . . . . . . . . . . 6
3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 5 3.1. ATM-based broadband aggregation . . . . . . . . . . . . . 6
3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7 3.2. Ethernet-based broadband aggregation . . . . . . . . . . . 7
4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7 4. Access Node Control Protocol . . . . . . . . . . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 9
4.3. ANCP based Line Configuration . . . . . . . . . . . . . . 10 4.3. ANCP based Line Configuration . . . . . . . . . . . . . . 10
4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 11
4.4. ANCP based Transactional Multicast . . . . . . . . . . . . 13 4.4. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 13
4.5. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 14 5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 14
4.5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 14 5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 20
5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 15 5.2. ANCP Connection keepalive . . . . . . . . . . . . . . . . 21
5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 19 5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 22
5.2. ANCP Connection keep-alive . . . . . . . . . . . . . . . . 20 5.4. GSMP Message Extensions for Access Node Control . . . . . 25
5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 21 5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 25
5.4. GSMP Message Extensions for Access Node Control . . . . . 24
5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 24
5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 26 5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 26
5.4.3. Line Configuration Extensions . . . . . . . . . . . . 36 5.4.3. Line Configuration Extensions . . . . . . . . . . . . 36
5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 39 5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 39
5.4.5. Additional GMSP Extensions for future use cases . . . 42 5.4.5. Additional GSMP Extensions for future use cases . . . 42
5.4.5.1. General well known TLVs . . . . . . . . . . . . . 43 5.4.5.1. General well known TLVs . . . . . . . . . . . . . 43
5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 43 5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 43
5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 44 5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 44
5.4.5.1.3. Status-Info TLV . . . . . . . . . . . . . . . 46 5.4.5.1.3. Status-info TLV . . . . . . . . . . . . . . . 46
5.5. ATM-specific considerations . . . . . . . . . . . . . . . 47 5.4.5.2. Generic Response Message . . . . . . . . . . . . . 47
5.6. Ethernet-specific considerations . . . . . . . . . . . . . 47 5.5. ATM-specific considerations . . . . . . . . . . . . . . . 49
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 5.6. Ethernet-specific considerations . . . . . . . . . . . . . 49
7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 6. Appendix: Handling of pre-RFC deployments of the ANCP
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
9.1. Normative References . . . . . . . . . . . . . . . . . . . 53 8. Security Considerations . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 53 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
10.1. Normative References . . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
1. Specification Requirements 1. Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
DSL is a widely deployed access technology for Broadband Access for DSL is a widely deployed access technology for Broadband Access for
skipping to change at page 5, line 5 skipping to change at page 4, line 51
Section 5. GSMPv3 procedures with suitable extensions, as used by Section 5. GSMPv3 procedures with suitable extensions, as used by
ANCP, are described in sections Section 5.1, Section 5.2 and ANCP, are described in sections Section 5.1, Section 5.2 and
Section 5.3. GSMPv3 general extensions and GSMPv3 message specific Section 5.3. GSMPv3 general extensions and GSMPv3 message specific
extensions required by ANCP are described in sub-sections of extensions required by ANCP are described in sub-sections of
Section 5.4. In addition to specifying extensions and modifications Section 5.4. In addition to specifying extensions and modifications
to relevant GSMP messages applicable to ANCP, this draft also defines to relevant GSMP messages applicable to ANCP, this draft also defines
the usage of these messages by ANCP. Not all the fields in relevant 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 GSMP messages are used by ANCP. This draft indicates the value that
ANCP should set for the fields in these GSMP messages. ANCP should set for the fields in these GSMP messages.
At the time of writing of this specification some implementations of
the ANCP protocol, based on pre-standards drafts are already
available. All these early-draft implementations use protocol
version/sub-version 3.1; standard ANCP protocol will use version/
sub-version 3.2 [Editor's note: sub-version needs to be changed from
1 to 2 upon publication.] Adopting a new sub-version value provides
a way to disambiguate the two protocols and allows for supporting
running a pre-standard and a standards compliant ANCP implementation
on any given ANCP node. The mechanism used to identify the protocol
version/sub-version is part of the adjacency negotiation process and
it is described in details in Section 5.2. It is important to note
that this mechanism does not guarantee backwards compatibility of the
ANCP RFC specification to those early-draft implementations.
2.1. Terminology 2.1. Terminology
o Access Node (AN): Network device, usually located at a service o Access Node (AN): Network device, usually located at a service
provider central office or street cabinet that terminates access provider central office or street cabinet that terminates access
(local) loop connections from subscribers. In case the access (local) loop connections from subscribers. In case the access
loop is a Digital Subscriber Line (DSL), the Access Node provides loop is a Digital Subscriber Line (DSL), the Access Node provides
DSL signal termination, and is referred to as DSL Access DSL signal termination, and is referred to as DSL Access
Multiplexer (DSLAM). Multiplexer (DSLAM).
o Network Access Server (NAS): Network element which aggregates o Network Access Server (NAS): Network element which aggregates
skipping to change at page 13, line 28 skipping to change at page 13, line 28
| | +------+ +-------+ | Gateway | +----------+ | | +------+ +-------+ | Gateway | +----------+
+-----------+ +---------+ +-----------+ +---------+
Figure 4: Message flow - ANCP mapping for Updated Line Configuration Figure 4: Message flow - ANCP mapping for Updated Line Configuration
The format of relevant extensions to port management message is The format of relevant extensions to port management message is
defined in section Section 5.4.3. The line configuration models defined in section Section 5.4.3. The line configuration models
could be viewed as a form of delegation of authorization from the NAS could be viewed as a form of delegation of authorization from the NAS
to the DSLAM. to the DSLAM.
4.4. ANCP based Transactional Multicast 4.4. ANCP based OAM
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 and additional use-cases will
be defined in a separate document.
4.5. ANCP based OAM
In a mixed Ethernet and ATM access network (including the local In a mixed Ethernet and ATM access network (including the local
loop), it is desirable to provide similar mechanisms for connectivity loop), it is desirable to provide similar mechanisms for connectivity
checks and fault isolation, as those used in an ATM based checks and fault isolation, as those used in an ATM based
architecture. This can be achieved using an ANCP based mechanism architecture. This can be achieved using an ANCP based mechanism
until end-to-end Ethernet OAM mechanisms are more widely implemented until end-to-end Ethernet OAM mechanisms are more widely implemented
in various network elements. in various network elements.
A simple solution based on ANCP can provide NAS with an access-line A simple solution based on ANCP can provide NAS with an access-line
test capability and to some extent fault isolation. Controlled by a test capability and to some extent fault isolation. Controlled by a
local management interface the NAS can use an ANCP operation to local management interface the NAS can use an ANCP operation to
trigger the access-node to perform a loopback test on the local-loop 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 (between the access-node and the CPE). The access-node can respond
via another ANCP operation the result of the triggered loopback test. via another ANCP operation the result of the triggered loopback test.
In case of ATM based local-loop the ANCP operation can trigger the 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. 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 In case of Ethernet, the access-node can trigger an Ethernet loopback
message(per EFM OAM) on the local-loop. message(per EFM OAM) on the local-loop.
4.5.1. Message Flow 4.4.1. Message Flow
"Port Management" message can be used by the NAS to request access "Port Management" message can be used by the NAS to request access
node to trigger a "remote loopback" test on the local loop. The node to trigger a "remote loopback" test on the local loop. The
result of the loopback test can be asynchronously conveyed by the result of the loopback test can be asynchronously conveyed by the
access node to the NAS in a "Port Management" response message. The access node to the NAS in a "Port Management" response message. The
format of relevant extensions to port management message is defined format of relevant extensions to port management message is defined
in section The format of relevant extensions to port management in section The format of relevant extensions to port management
message is defined in section Section 5.4.4. Figure 5 summarizes the message is defined in section Section 5.4.4. Figure 5 summarizes the
interaction. interaction.
skipping to change at page 16, line 16 skipping to change at page 15, line 37
field to be 12 bits long. field to be 12 bits long.
Version: Version:
The version number of the GSMP protocol being used in this The version number of the GSMP protocol being used in this
session. ANCP uses version 3. session. ANCP uses version 3.
Sub-Version: Sub-Version:
The sub-version number of the GSMP protocol being used in this The sub-version number of the GSMP protocol being used in this
session. ANCP uses sub-version 1 of the GSMP protocol. session. ANCP uses sub-version 1 of the GSMP protocol. [RFC
Editor's note: sub-version needs to be changed from 1 to 2 upon
publication]
Result: Result:
The Result field derived from GSMP [RFC3292] has the following The Result field derived from GSMP [RFC3292] has the following
codes: codes:
Ignore: Ignore:
Res = 0x00 - Ignore this field on receipt and follow the Res = 0x00 - Ignore this field on receipt and follow the
procedures specified for the received message type. procedures specified for the received message type.
skipping to change at page 17, line 29 skipping to change at page 17, line 17
Code: Code:
This field gives further information concerning the result in a This field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a response message. It is mostly used to pass an error code in a
failure response but can also be used to give further information failure response but can also be used to give further information
in a success response message or an event message. In a request in a success response message or an event message. In a request
message, the code field is not used and is set to zero. In an message, the code field is not used and is set to zero. In an
adjacency protocol message, the Code field is used to determine adjacency protocol message, the Code field is used to determine
the function of the message. the function of the message.
Partition ID: ANCP implementations MAY use any of the Code values specified in
the IANA registry "Global Switch Management Protocol version 3
(GSMPv3) Failure Response Message Name Space" if they appear
applicable. In particular, the values:
This field is a 8 bit number which signifies a partition on the 2 Invalid request message (i.e., a properly formed message which
AN. [ TBD How AN and NAS agree on the partition numbers. Possible violates the protocol through its timing or direction of
options: transmission)
1 - The partition ID could be configured on the AN and learnt by 4 One or more of the specified ports do not exist
NAS in the adjacency message;
2 - The partition ID could be statically configured on the NAS as 6 One or more of the specified ports are down
part of configuring the neighbor information.]
7 Invalid Partition ID
19 Out of resources (e.g. memory exhausted, etc.)
30 The limit on the maximum number of point-to- multipoint
connections that the switch can support has been reached
31 The limit on the maximum number of branches that the specified
point-to-multipoint connection can support has been reached
may unfortunately apply to ANCP usage, including the case where
"Port" is interpreted to mean Target as defined in section
Section 5.4.5.1.1
Instead of the value:
3 The specified request is not implemented on this switch
specified by [RFC3292], this specification defines a new value:
81 Request message type not implemented
This value MAY be sent in a failure response from either the AN or
the NAS. This specification also defines the additional values:
82 Transaction identifier out of sequence
83 Malformed message
84 TLV or value not supported by negotiated capability set
ANCP extensions defining new code values SHOULD use the range 0x0100
through 0x01ff for this purpose.
The range of values from 256 to 4095 is reserved for IETF use.
Partition ID:
This field is a 8 bit number which signifies a partition on the
AN.
Transaction ID: Transaction ID:
24-bit field set by the sender of a Request message to associate a 24-bit field set by the sender of a Request message to associate a
Response message with the original Request message. The receiver Response message with the original Request message. The receiver
of a Request message reflects the transaction ID from the Request of a Request message reflects the transaction ID from the Request
message in the corresponding Response message. For event message in the corresponding Response message. For event
messages, the transaction identifier SHOULD be set to zero. The messages, the transaction identifier SHOULD be set to zero. The
Transaction Identifier is not used, and the field is not present, Transaction Identifier is not used, and the field is not present,
in the adjacency protocol. in the adjacency protocol.
skipping to change at page 20, line 44 skipping to change at page 21, line 11
In the case of ATM access, a separate PVC (control channel) capable In the case of ATM access, a separate PVC (control channel) capable
of transporting IP would be configured between NAS and the DSLAM for of transporting IP would be configured between NAS and the DSLAM for
ANCP messages. ANCP messages.
In case of an Ethernet access/aggregation network, a typical practice In case of an Ethernet access/aggregation network, a typical practice
is to send the Access Node Control Protocol messages over a dedicated is to send the Access Node Control Protocol messages over a dedicated
Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN
ID). ID).
5.2. ANCP Connection keep-alive 5.2. ANCP Connection keepalive
GSMPv3 defines an adjacency protocol. The adjacency protocol is used GSMPv3 defines an adjacency protocol. The adjacency protocol is used
to synchronize states across the link, to negotiate which version of 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 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 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 hard state protocol. It is therefore important to detect loss of
contact between switch and controller, and to detect any change of contact between switch and controller, and to detect any change of
identity of switch or controller. No protocol messages other than identity of switch or controller. No protocol messages other than
those of the adjacency protocol may be sent across the link until the those of the adjacency protocol may be sent across the link until the
adjacency protocol has achieved synchronization. There are no adjacency protocol has achieved synchronization. There are no
skipping to change at page 21, line 26 skipping to change at page 21, line 41
adjacency message and agree to use the higher of the two values. adjacency message and agree to use the higher of the two values.
That is, the node that receives a higher timer value than its own, That is, the node that receives a higher timer value than its own,
will reply in its subsequent adjacency messages (such as SYNACK, ACK) will reply in its subsequent adjacency messages (such as SYNACK, ACK)
with the higher timer value. with the higher timer value.
The GSMP adjacency message defined in [RFC3292] is extended for ANCP The GSMP adjacency message defined in [RFC3292] is extended for ANCP
and is shown in section 5.3 immediately following this section. The and is shown in section 5.3 immediately following this section. The
8-bit "version" field in the adjacency protocol messages is modified 8-bit "version" field in the adjacency protocol messages is modified
to carry the version and sub-version of the GSMP protocol for version 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. negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol.
[RFC Editor's note: sub-version needs to be changed from 1 to 2 upon
publication.] In the adjacency protocol the version and the sub-
version fields are used for version negotiation. The version
negotiation is performed before synchronisation is achieved. In a
SYN message the version/sub-version fields always contain the highest
version understood by the sender. A receiver receiving a SYN message
with a version/sub-version higher than understood will ignore that
message. A receiver receiving a SYN message with a version/
sub-vresion lower than its own highest version/sub-version, but a
version/sub-version that it understands, will reply with a SYNACK
with the version/sub-version from the received SYN in its ANCP
version/sub-version fields. This defines the version/sub-version of
the ANCP protocol to be used while the adjacency protocol remains
synchronised. All other messages will use the agreed version in the
version/sub-version fields.
The semantics and suggested values for Code, "Sender Name", "Receiver The semantics and suggested values for Code, "Sender Name", "Receiver
Name", "Sender Instance", and "Receiver Instance" fields are as Name", "Sender Instance", and "Receiver Instance" fields are as
defined in [RFC3292]. The "Sender Port", and "Receiver Port" should 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 be set to 0 by both ends. The pType field should be set to 0. The
pFlag should be set to 1. pFlag should be set to 1.
If the adjacency times out on either end, due to not receiving an If the adjacency times out on either end, due to not receiving an
adjacency message for a duration of (3 * Timer value), where the adjacency message for a duration of (3 * Timer value), where the
timer value is specified in the adjacency message, all the state timer value is specified in the adjacency message, all the state
received from the ANCP neighbor should be cleaned up, and the TCP received from the ANCP neighbor should be cleaned up, and the TCP
skipping to change at page 25, line 28 skipping to change at page 26, line 4
These are generally used by specific messages and will be These are generally used by specific messages and will be
defined in those messages. defined in those messages.
Message Type Message Type
An 8-bit field corresponding to the message type where the An 8-bit field corresponding to the message type where the
extension block is used. extension block is used.
Tech Type Tech Type
An 8-bit field indicating the applicable technology type value. An 8-bit field indicating the applicable technology type value.
The Message Type plus the Tech Value uniquely define a single The Message Type plus the Tech Value uniquely define a single
Extension Type and can be treated as a single 16 bit extension 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 type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL
technology. technology and 0x01 for PON technology.
0x00 Extension block not in use. 0x00 Extension block not in use
0x01 - 0x04 Already in use by various technologies 0x01 PON
0x05 DSL 0x05 DSL
0x06 - 0xFE Reserved 0x06 - 0xFE Reserved
0xFF Base Specification Use 0xFF Base Specification Use
Block Length Block Length
A 8-bit field indicating the length of the Extension Value A 8-bit field indicating the length of the Extension Value
skipping to change at page 42, line 38 skipping to change at page 42, line 38
Value : Suitably formatted ASCII string containing useful Value : Suitably formatted ASCII string containing useful
details about the test that the NAS will display for the details about the test that the NAS will display for the
operator, exactly as received from the DSLAM (no manipulation/ operator, exactly as received from the DSLAM (no manipulation/
interpretation by the NAS). This is an optional TLV, but it is interpretation by the NAS). This is an optional TLV, but it is
strongly recommended, that in case of ATM based local loop, the strongly recommended, that in case of ATM based local loop, the
DSLAM at the very least indicates via this TLV, the total DSLAM at the very least indicates via this TLV, the total
loopback cells generated and the total loopback cells loopback cells generated and the total loopback cells
successfully received as part of executing the requested successfully received as part of executing the requested
loopback test. loopback test.
5.4.5. Additional GMSP Extensions for future use cases 5.4.5. Additional GSMP Extensions for future use cases
GSMP protocol defined in [RFC3292] allows for two messaging GSMP protocol defined in [RFC3292] allows for two messaging
principles in case of Request/Response interaction: principles in case of Request/Response interaction:
o The same message type used for both request message and response o The same message type used for both request message and response
message where result field and code field settings are used to message where result field and code field settings are used to
differentiate between request and response messages; differentiate between request and response messages;
o Two different message types for request message and response o Two different message types for request message and response
messages. messages.
skipping to change at page 43, line 46 skipping to change at page 43, line 46
reflected in the message length field. reflected in the message length field.
5.4.5.1. General well known TLVs 5.4.5.1. General well known TLVs
This section contains the definitions of three general well known This section contains the definitions of three general well known
TLVs. These TLVs are intended to be re-usable across different TLVs. These TLVs are intended to be re-usable across different
messages. messages.
5.4.5.1.1. Target TLV 5.4.5.1.1. Target TLV
The Target TLV (0x10) is intended to be a general well known TLV The Target TLV (0x1000 - 0x01020) is intended to be a general well
allowing the representation of different types of objects. Its use known TLV allowing the representation of different types of objects.
is not restricted to any specific Message Type. 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 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 | | TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Target Info ~ ~ Target Info ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target TLV: Target TLV:
TLV (0x10) indicating the type of target being addressed. TLV (0x1000 - 0x1020) indicating the type of target being
Tentative 0x1000 for single Access-Port. addressed. Target TVL 0x1000 indicates a single Access-
Port.
Target TLV Length: Target TLV Length:
Length in bytes of Target Info. Excludes TLV header Length in bytes of Target Info. Excludes TLV header
Target Info: Target Info:
Target information as defined for each the given target. Target information as defined for each the given target.
The field can consist of sub-TLVs. The field can consist of sub-TLVs.
In its simplest form, when targeting a single access line the Target- 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 TLV will be set to a value of (0x1000), and carry in its payload one
more sub-TLVs identifying the target. The following example or more sub-TLVs identifying the target. The following example
illustrates the message format for a single port identified by an illustrates the message format for a single port identified by an
Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a Access-Loop-Circuit-ID TLV (0x0001) that could be derived from a
Port-UP message: 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 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 | | TLV Type = Target | Target-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 46, line 5 skipping to change at page 46, line 5
Additional sub-TLV: Additional sub-TLV:
Additional sub-TLVs can be present in a command TLV. Any Additional sub-TLVs can be present in a command TLV. Any
such sub-TLVs must directly follow each command. such sub-TLVs must directly follow each command.
Additional sub-TLV Length: Additional sub-TLV Length:
Number of actual bytes contained in the value portion of Number of actual bytes contained in the value portion of
each additional sub-TLV each additional sub-TLV
5.4.5.1.3. Status-Info TLV 5.4.5.1.3. Status-info TLV
The Status-info-TLV is intended to be a general well known TLV used 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 to convey the status code regarding commands and/or requests. The
format of the Status-Info-TLV (0x012) is shown below. format of the Status-info-TLV (0x0106) is shown below.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | TLV Type = Status-info | Status TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmnd Nmbr | Error Message Length | | Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (aligned to 4 bytes length) | | Error Message (aligned to 4 bytes length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs... | | sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Status-info TLV: Status-info TLV:
TLV (0x12) conveying the status or error response of a TLV (0x106) conveying the status or error response of a
command command
Status TLV Length: Status TLV Length:
Specifies the length in bytes of the Status Info TLV Specifies the length in bytes of the Status Info TLV
payload. Excludes the TLV header payload. Excludes the TLV header
Result Code: Reserved:
Conveys the result code for the command or message, as This field MUST be set to all zeroes by the sender and
defined by the application. ignored by the receiver.
Cmnd Nmbr: Msg Type:
Contains the command number copied from the Request The message type value of the message the Status-info TLV
message. The value of 0 is used whenever the error is not is reporting on
specific to a command.
Error Message Length: Error Message Length:
Contains the length of an optional error message or 0 if It contains the length of an optional error message or 0 if
none. none.
Error message:
It contains a human-readable description of the error being
reported by the Status-info field.
TLVs: TLVs:
This field is of indeterminate length, and contains zero or This field is of indeterminate length, and contains zero or
more of the TLVs associated with the Status-info-TLV. more of the TLVs associated with the Status-info TLV. The
following TLVs are RECOMMENDED to be provided if the
indicated Code values are given in the header of the
message containing the Status-info TLV:
Code value 4 or 5: the Target or other TLV identifying the
unknown or unavailable port.
Code value 84: the TLV that is unsupported or contains the
unsupported value.
5.4.5.2. Generic Response Message
This section defines the Generic Response message. The Generic
Response message may be specified as the appropriate response to a
message defined in an extension to ANCP, instead of a more specific
response message. As a general guideline, specification of the
Generic Response message as a response is appropriate where no data
needs to be returned to the peer other than a result (success or
failure), plus, in the case of a failure, a code indicating the
reason for failure and a limited amount of diagnostic data.
Depending on the particular use case, the Generic Response message
MAY be sent by either the NAS or the AN.
The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this
case, the sender MUST set the Transaction Identifier field in the
header and the Message Type field within the Status-info TLV to
zeroes. The receiver MAY record the information contained in the
Status-info TLV for management use.
The format of the Generic Response message is shown in Figure 17
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 |Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=0x106 | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Structure of the Generic Response Message
Message Type:
The message type value for the Generic Response message is 0x91.
Result:
The value of the Result field for the Generic Response message
MUST be either Success (0x03) or Failure (0x04).
Code:
The Code field MUST have value zero if Result is set to Success
(0x03). It MUST have an appropriate non-zero value if Result is
set to Failure (0x04). As discussed in section 5, extensions to
ANCP MAY define new Code values for use in failure responses for
specific request message types.
Partition ID:
As specified in section Section 5.
Transaction Identifier:
The Transaction Identifier MUST be copied from the request to
which the Generic Response message is responding.
I, Sub-message Number, Length:
As specified in Section 5.
Status-info TLV:
MAY be present in a success response, to provide a warning as
defined for a specific request message type. MUST be present in a
failure response. The Message Type field value is copied from the
header of the request message. The Error Message field contains
human-readable diagnostic text. The description of the response
for a particular request message type MAY specify further sub-TLVs
to be included in Status-info, either generally or for specific
failure Code values.
5.5. ATM-specific considerations 5.5. ATM-specific considerations
The topology discovery and line configuration involve the DSL line The topology discovery and line configuration involve the DSL line
attributes. For ATM based access networks, the DSL line on the DSLAM attributes. For ATM based access networks, the DSL line on the DSLAM
is identified by the port and PVP/PVC corresponding to the is identified by the port and PVP/PVC corresponding to the
subscriber. The DSLAMs are connected to the NAS via an ATM access subscriber. The DSLAMs are connected to the NAS via an ATM access
aggregation network. Since, the DSLAM (access-node) is not directly aggregation network. Since, the DSLAM (access-node) is not directly
connected to the NAS, the NAS needs a mechanism to learn the DSL line connected to the NAS, the NAS needs a mechanism to learn the DSL line
identifier (more generally referred to as "Access Loop Circuit-ID") identifier (more generally referred to as "Access Loop Circuit-ID")
skipping to change at page 48, line 9 skipping to change at page 50, line 27
discovery and line configuration messages, and then hve a mechanism discovery and line configuration messages, and then hve a mechanism
by which this can be correlated to the context of an "aggregation by which this can be correlated to the context of an "aggregation
network" facing IP interface (for the subscriber) on the NAS. This 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 can either be based on local configuration on the NAS, or on the fact
that such DSLAM (access node) typically inserts the "Access Loop that such DSLAM (access node) typically inserts the "Access Loop
Circuit ID" in subscriber signaling messages relayed to the NAS (i.e. Circuit ID" in subscriber signaling messages relayed to the NAS (i.e.
DHCP or PPPoE discovery messages). DHCP or PPPoE discovery messages).
Section Section 5.4.1 defines "Access Loop Circuit ID". Section Section 5.4.1 defines "Access Loop Circuit ID".
6. IANA Considerations 6. Appendix: Handling of pre-RFC deployments of the ANCP protocol
This appendix is non normative.
Prior to completion of this document, several pre-RFC versions of the
protocol were documented and implemented. There were numerous pre-
standard versions of the protocol all using a version/sub-version
fields set to 3.1.
A NAS implementing the ANCP protocol as defined in this document may,
on a peer basis, use the version and sub-version fields to detect a
pre-RFC implementation of the protocol and choose to work with such
pre-RFC peers. The version and sub-version negotiation phase is part
of the adjacency protocol and is performed before synchronisation is
achieved.
7. IANA Considerations
This document defines the following additions to the GSMPv3 Message This document defines the following additions to the GSMPv3 Message
Type Name Space registry: Type Name Space registry:
+--------------+--------+---------------+ +--------------+--------+---------------+
| Message | Number | Source | | Message | Number | Source |
+--------------+--------+---------------+ +--------------+--------+---------------+
| Provisioning | 93 | This document | | Provisioning | 93 | This document |
+--------------+--------+---------------+ +--------------+--------+---------------+
skipping to change at page 49, line 40 skipping to change at page 52, line 23
This document defines a new ANCP Version Space registry. The initial This document defines a new ANCP Version Space registry. The initial
entry is as follows: entry is as follows:
+--------------------+-------------------+---------------+ +--------------------+-------------------+---------------+
| ANCP Version Value | ANCP Version Name | Reference | | ANCP Version Value | ANCP Version Name | Reference |
+--------------------+-------------------+---------------+ +--------------------+-------------------+---------------+
| 3 | ANCP Version | This document | | 3 | ANCP Version | This document |
+--------------------+-------------------+---------------+ +--------------------+-------------------+---------------+
This document defines a new ANCP Version Space registry. The initial This document defines a new ANCP Sub-Version Space registry. The
entry is as follows: initial entry is as follows:
+------------------------+-----------------------+---------------+ +------------------------+-----------------------+---------------+
| ANCP Sub-Version Value | ANCP Sub-Version Name | Reference | | ANCP Sub-Version Value | ANCP Sub-Version Name | Reference |
+------------------------+-----------------------+---------------+ +------------------------+-----------------------+---------------+
| 1 | ANCP Sub-Version | This document | | 1 [*] | ANCP Sub-Version | This document |
+------------------------+-----------------------+---------------+ +------------------------+-----------------------+---------------+
[*] Editor's note: sub-version needs to be changed from 1 to 2 upon
publication
This document defines a new ANCP Tech Type Name Space registry. The This document defines a new ANCP Tech Type Name Space registry. The
initial entries are as follows: initial entries are as follows:
+----------------+-----------------------------------+--------------+ +-----------------+----------------------------+---------------+
| Tech Type | Tech Type Name | Reference | | Tech Type Value | Tech Type Name | Reference |
| Value | | | +-----------------+----------------------------+---------------+
+----------------+-----------------------------------+--------------+ | 0x00 | Extension block not in use | This document |
| 0x00 | Extension block not in use | This | | 0x01 | PON | This document |
| | | document | | 0x05 | DSL | This document |
| 0x01 - 0x04 | Already in use by various | This | | 0x06 - 0xFE | Reserved | This document |
| | technologies | document | | 0xFF | Base Specification Use | This 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. This document reserves the range 0x500 to 0x5ff of GSMPv3 Failure
The initial entries are as follows: Response Message Name Space registry.
+--------------------------------+-------+---------------+ This document adds the following values to the GSMPv3 Failure
| Result Code | Value | Reference | Response Message Name Space registry:
+--------------------------------+-------+---------------+
| Success | 0x00 | This document | +--------------------------------------+----------------+-----------+
| Malformed message | 0x01 | This document | | Command Code Directive Name | Command Code | Reference |
| Command not supported | 0x02 | This document | | | Value | |
| Unrecognized Target | 0x04 | This document | +--------------------------------------+----------------+-----------+
| No resources | 0x07 | This document | | Request message type not implemented | 0x81 | This |
| Unknown Target | 0x08 | This document | | | | document |
| Target down | 0x09 | This document | | Transaction identifier out of | 0x82 | This |
| Transaction-id out of sequence | 0x010 | This document | | sequence | | document |
+--------------------------------+-------+---------------+ | Malformed message | 0x83 | This |
| | | document |
| TLV or value not supported by | 0x84 | This |
| negotiated capability set | | document |
| From 0x256 to 0x4095 | Reserved for | This |
| | IETF use | document |
+--------------------------------------+----------------+-----------+
This document reserves the values 0x100 to 0x1ff (256 to 511) within
the GSMPv3 Failure Response Message Name Space registry for use by
extensions to the Access Node Control Protocol (ANCP).
This document defines a new ANCP Command Code registry. The initial This document defines a new ANCP Command Code registry. The initial
entries are as follows: entries are as follows:
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| Command Code Directive Name | Command Code Value | Reference | | Command Code Directive Name | Command Code Value | Reference |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| Reserved | 0x00 | This document | | Reserved | 0x00 | This document |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
This document defines a new ANCP TLV Type registry. The initial This document defines a new ANCP TLV Type registry. The initial
entries are as follows: entries are as follows:
+--------------------------------------+-----------+---------------+ +--------------------------------------+--------------+-------------+
| TLV Name | Type Code | Reference | | TLV Name | Type Code | Reference |
+--------------------------------------+-----------+---------------+ +--------------------------------------+--------------+-------------+
| Access-Loop-Circuit-ID | 0x01 | This document | | Access-Loop-Circuit-ID | 0x01 | This |
| Access-Loop-Remote-Id | 0x02 | This document | | | | document |
| Access-Aggregation-Circuit-ID-ASCII | 0x03 | This document | | Access-Loop-Remote-Id | 0x02 | This |
| DSL Line Attributes | 0x04 | This document | | | | document |
| Service-Profile-Name | 0x05 | This document | | Access-Aggregation-Circuit-ID-ASCII | 0x03 | This |
| Access-Aggregation-Circuit-ID-Binary | 0x06 | This document | | | | document |
| OAM-Loopback-Test-Parameters | 0x07 | This document | | DSL Line Attributes | 0x04 | This |
| Opaque-Data | 0x08 | This document | | | | document |
| OAM-Loopback-Test-Response-String | 0x09 | This document | | Service-Profile-Name | 0x05 | This |
| Reserved | 0x0a-0x0f | This document | | | | document |
| Target | 0x10 | This document | | Access-Aggregation-Circuit-ID-Binary | 0x06 | This |
| Command | 0x11 | This document | | | | document |
| Status-Info | 0x012 | This document | | OAM-Loopback-Test-Parameters | 0x07 | This |
+--------------------------------------+-----------+---------------+ | | | document |
| Opaque-Data | 0x08 | This |
| | | document |
| OAM-Loopback-Test-Response-String | 0x09 | This |
| | | document |
| Reserved | 0x0a-0x0f | This |
| | | document |
| Target | 0x1000 - | This |
| | 0X1020 | document |
| Command | 0x11 | This |
| | | document |
| Status-info | 0x0106 | This |
| | | document |
+--------------------------------------+--------------+-------------+
This document defines a new ANCP Capability registry. The initial This document defines a new ANCP Capability registry. The initial
entries are as follows: entries are as follows:
+----------------------------+----------------------+---------------+ +----------------------------+----------------------+---------------+
| Capability Type Name | Capability Type Code | Reference | | Capability Type Name | Capability Type Code | Reference |
+----------------------------+----------------------+---------------+ +----------------------------+----------------------+---------------+
| Dynamic-Topology-Discovery | 0x01 | This document | | Dynamic-Topology-Discovery | 0x01 | This document |
| Line-Configuration | 0x02 | This document | | Line-Configuration | 0x02 | This document |
| Transactional-Multicast | 0x03 | This document | | Transactional-Multicast | 0x03 | This document |
skipping to change at page 52, line 45 skipping to change at page 55, line 45
| Actual-Interleaving-Delay-Downstream | 0x8E | This | | Actual-Interleaving-Delay-Downstream | 0x8E | This |
| | | document | | | | document |
| DSL line state | 0x8F | This | | DSL line state | 0x8F | This |
| | | document | | | | document |
| Access Loop Encapsulation | 0x90 | This | | Access Loop Encapsulation | 0x90 | This |
| | | document | | | | document |
| DSL-Type | 0x91 | This | | DSL-Type | 0x91 | This |
| | | document | | | | document |
+--------------------------------------------+--------+-------------+ +--------------------------------------------+--------+-------------+
7. Security Considerations 8. Security Considerations
Security of the ANCP protocol is discussed in [ANCP-SEC] Security of the ANCP protocol is discussed in [ANCP-SEC]
8. Acknowledgements 9. Acknowledgements
The authors would like to thank everyone that has provided comments The authors would like to thank everyone that has provided comments
or inputs to this document. In particular, the authors acknowledge or inputs to this document. In particular, the authors acknowledge
the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler, the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel
Platnic and Tom Taylor. Platnic and Tom Taylor.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
January 2001. January 2001.
[RFC3292] Doria, A. and et all, "General Switch Management Protocol [RFC3292] Doria, A. and et all, "General Switch Management Protocol
(GSMP) V3", June 2002. (GSMP) V3", June 2002.
[RFC3293] Worster, T., Doria, A., and and J. Buerkle, "General [RFC3293] Worster, T., Doria, A., and and J. Buerkle, "General
Switch Management Protocol (GSMP) Packet Encapsulations Switch Management Protocol (GSMP) Packet Encapsulations
for Asynchronous Transfer Mode (ATM), Ethernet and for Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", June 2002. Transmission Control Protocol (TCP)", June 2002.
9.2. Informative References 10.2. Informative References
[ANCP-FRAMEWORK] [ANCP-FRAMEWORK]
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-10.txt, work in progress, draft-ietf-ancp-framework-12.txt, work in progress,
May 2009. October 2009.
[ANCP-SEC] [ANCP-SEC]
Moustafa, H., Tschofenig, T., and S. De Cnodder, "Security Moustafa, H., Tschofenig, T., and S. De Cnodder, "Security
Threats and Security Requirements for the Access Node Threats and Security Requirements for the Access Node
Control Protocol (ANCP)", Control Protocol (ANCP)",
draft-ietf-ancp-security-threats-08.txt work in progress, draft-ietf-ancp-security-threats-08.txt work in progress,
July 2009. July 2009.
[G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair [G.988.1] "ITU-T recommendation G.998.1, ATM-based multi-pair
bonding", 2005. bonding", 2005.
 End of changes. 51 change blocks. 
148 lines changed or deleted 329 lines changed or added

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