draft-ietf-ancp-protocol-05.txt   draft-ietf-ancp-protocol-06.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: September 10, 2009 Juniper Networks Expires: January 14, 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
March 9, 2009 July 13, 2009
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-05 draft-ietf-ancp-protocol-06
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 September 10, 2009. This Internet-Draft will expire on January 14, 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 23 skipping to change at page 3, line 23
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 Transactional Multicast . . . . . . . . . . . . 13
4.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Message Flow . . . . . . . . . . . . . . . . . . . . . 14
4.5. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 14 4.5. ANCP based OAM . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 15 4.5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . 14
5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 15 5. Access Node Control Protocol (ANCP) . . . . . . . . . . . . . 15
5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 19 5.1. ANCP/TCP connection establishment . . . . . . . . . . . . 19
5.2. ANCP Connection keep-alive . . . . . . . . . . . . . . . . 21 5.2. ANCP Connection keep-alive . . . . . . . . . . . . . . . . 20
5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 21 5.3. Capability negotiation . . . . . . . . . . . . . . . . . . 21
5.4. GSMP Message Extensions for Access Node Control . . . . . 24 5.4. GSMP Message Extensions for Access Node Control . . . . . 24
5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 24 5.4.1. General Extensions . . . . . . . . . . . . . . . . . . 24
5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 25 5.4.2. Topology Discovery Extensions . . . . . . . . . . . . 26
5.4.3. Line Configuration Extensions . . . . . . . . . . . . 35 5.4.3. Line Configuration Extensions . . . . . . . . . . . . 36
5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 38 5.4.4. OAM Extensions . . . . . . . . . . . . . . . . . . . . 39
5.4.5. Multicast Extensions . . . . . . . . . . . . . . . . . 41 5.4.5. Additional GMSP Extensions for future use cases . . . 42
5.4.5.1. General well known TLVs . . . . . . . . . . . . . 42 5.4.5.1. General well known TLVs . . . . . . . . . . . . . 43
5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 42 5.4.5.1.1. Target TLV . . . . . . . . . . . . . . . . . . 43
5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 43 5.4.5.1.2. Command TLV . . . . . . . . . . . . . . . . . 44
5.4.5.1.3. Status-Info TLV . . . . . . . . . . . . . . . 44 5.4.5.1.3. Status-Info TLV . . . . . . . . . . . . . . . 46
5.4.5.2. Multicast Replication Control Message . . . . . . 45 5.5. ATM-specific considerations . . . . . . . . . . . . . . . 47
5.4.5.3. Multicast Status Message . . . . . . . . . . . . . 51 5.6. Ethernet-specific considerations . . . . . . . . . . . . . 47
5.5. ATM-specific considerations . . . . . . . . . . . . . . . 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
5.6. Ethernet-specific considerations . . . . . . . . . . . . . 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
7. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
9.2. Informative References . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
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 4, line 31 skipping to change at page 4, line 31
required, which implies a tighter coordination between network required, which implies a tighter coordination between network
elements in the broadband access network without burdening the OSS elements in the broadband access network without burdening the OSS
layer. layer.
This draft defines extensions and modifications to GSMPv3 (specified This draft defines extensions and modifications to GSMPv3 (specified
in [RFC3292]) and certain new mechanisms to realize a control plane in [RFC3292]) and certain new mechanisms to realize a control plane
between a service-oriented layer 3 edge device (the NAS) and a layer2 between a service-oriented layer 3 edge device (the NAS) and a layer2
Access Node (e.g. DSLAM) in order to perform QoS-related, service- Access Node (e.g. DSLAM) in order to perform QoS-related, service-
related and subscriber-related operations. The control protocol as a related and subscriber-related operations. The control protocol as a
result of these extensions and mechanisms is referred to as "Access result of these extensions and mechanisms is referred to as "Access
Node Control Protocol" (ANCP). Node Control Protocol" (ANCP). Although ANCP is based on GSMPv3, it
is not interoperable with GSMPv3 defined in [RFC3292].
ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP
encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3 encapsulation for GSMPv3 is defined in [RFC3293]. GSMPv3
encapsulation directly over Ethernet and ATM as defined in [RFC3293] encapsulation directly over Ethernet and ATM as defined in [RFC3293]
is not considered for ANCP. is not considered for ANCP.
ANCP uses a subset of GSMPv3 messages to implement currently defined ANCP uses a subset of GSMPv3 messages to implement currently defined
use-cases. These relevant GSMPv3 messages are identified in section use-cases. These relevant GSMPv3 messages are identified in section
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
skipping to change at page 13, line 52 skipping to change at page 13, line 52
given access-node, and let the access-node perform multicast given access-node, and let the access-node perform multicast
replication by layer2 means (e.g. ATM point-to-multipoint cell replication by layer2 means (e.g. ATM point-to-multipoint cell
replication or Ethernet data-link bridging) for subscribers behind replication or Ethernet data-link bridging) for subscribers behind
the access-node. However, operationally, NAS is the ideal choice to the access-node. However, operationally, NAS is the ideal choice to
handle subscriber management functions (authentication, handle subscriber management functions (authentication,
authorization, accounting and address management), multicast policies authorization, accounting and address management), multicast policies
such as per-channel authorization, and complex multicast routing such as per-channel authorization, and complex multicast routing
protocols. Therefore, some means is needed for the NAS to setup protocols. Therefore, some means is needed for the NAS to setup
multicast replication state in the access-nodes. In ATM access multicast replication state in the access-nodes. In ATM access
networks, ANCP can be used by the NAS to setup P2MP cross-connects in networks, ANCP can be used by the NAS to setup P2MP cross-connects in
the DSLAMs. Protocol support for this use-case is defined in section the DSLAMs. Protocol support for this and additional use-cases will
Section 5.4.5 be defined in a separate document.
4.4.2. Message Flow
The Multicast Replication Control Message is sent by the NAS to the
AN with a directive to either join or leave one or more multicast
flows. The AN will use a Multicast Status Message when conveying the
outcome of the directive. The message flows in Figure 5 illustrates
the behavior of the AN in case of receiving a Multicast Replication
Control Message.
+----------+ +-------+ +-----+ ANCP +-----+
|Subscriber| | Home | | AN |<-------------------->| NAS |
+----------+ |Gateway| +-----+ +-----+
| +-------+ | |
| | | Multicast-Replication-Crl |
| | |(Target,add, Flowi..Flowj) |
| | |<--------------------------|
| Mcast Flow 1 | |
|<==========================+ |
| | | Multicast-Status |
| | |-------------------------->|
| | | |
| | | Multicast-Replication-Crl |
| | |(Target,delete,Flowi.Flowj)|
| | |<--------------------------|
| | | |
| <Stop Replication of X |
| Mcast Flow 1> | Multicast-Status |
| | |-------------------------->|
Figure 5: NAS-Controlled Multicast Replication
4.5. ANCP based OAM 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.
skipping to change at page 15, line 18 skipping to change at page 14, line 34
message(per EFM OAM) on the local-loop. message(per EFM OAM) on the local-loop.
4.5.1. Message Flow 4.5.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 6 summarizes the message is defined in section Section 5.4.4. Figure 5 summarizes the
interaction. interaction.
Port Management Message Port Management Message
(Remote Loopback ATM loopback (Remote Loopback ATM loopback
Trigger Request) OR EFM Loopback Trigger Request) OR EFM Loopback
1. ----------------> 2. ---------> 1. ----------------> 2. --------->
<--------+ <--------+
+-------------+ +-----+ +-------+ +----------------+ +-------------+ +-----+ +-------+ +----------------+
|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)
Figure 6: Message Flow: ANCP based OAM Figure 5: Message Flow: ANCP based OAM
5. Access Node Control Protocol (ANCP) 5. Access Node Control Protocol (ANCP)
ANCP uses a subset of GSMPv3 messages described in [RFC3292] to ANCP uses a subset of GSMPv3 messages described in [RFC3292] to
implement currently defined use-cases. GSMPv3 general message implement currently defined use-cases. GSMPv3 general message
format, used by all GSMP messages other than adjacency protocol format, used by all GSMP messages other than adjacency protocol
messages, is defined in section 3.1.1 of GSMPv3 [RFC3292]. ANCP messages, is defined in section 3.1.1 of GSMPv3 [RFC3292]. ANCP
modifies this base GSMPv3 message format. The modified GSMPv3 modifies this base GSMPv3 message format. The modified GSMPv3
message format is defined as follows: message format is defined as follows:
skipping to change at page 16, line 19 skipping to change at page 15, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier | | Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length | |I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Message Payload ~ ~ Message Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Modified GSMPv3 message format Figure 6: Modified GSMPv3 message format
The 8-bit version field in the base GSMPv3 message header is split 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 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 the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP
protocol. An ANCP implementation SHOULD always set the version field protocol. An ANCP implementation SHOULD always set the version field
to 3, and the sub-version field to 1. The Result field in the 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 message header has been modified to be 4 bits long, and the Code
field to be 12 bits long. field to be 12 bits long.
Version: Version:
skipping to change at page 18, line 28 skipping to change at page 18, line 11
part of configuring the neighbor information.] part of configuring the neighbor information.]
Transaction ID: Transaction ID:
24-bit field set by the sender of a Request message to associate a 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. The specific use of transaction ID as in the adjacency protocol.
applicable to multicast use case is defined in Section 5.4.5
I flag: I flag:
An ANCP implementation SHOULD set "I" and subMessage fields to 1 An ANCP implementation SHOULD set "I" and subMessage fields to 1
to signify no fragmentation. to signify no fragmentation.
Length: Length:
Length of the GSMP message including its header fields and defined Length of the GSMP message including its header fields and defined
GSMP message body. GSMP message body.
skipping to change at page 20, line 20 skipping to change at page 20, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length | | Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ GSMP Message ~ ~ GSMP Message ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GSMPv3 with TCP/IP Encapsulation message format Figure 7: GSMPv3 with TCP/IP Encapsulation message format
Type Type
This 2-byte field indicates the type code of the following This 2-byte field indicates the type code of the following
message. The type code for GSMP messages is 0x88-0C (i.e., the message. The type code for GSMP messages is 0x88-0C (i.e., the
same as GSMP's Ethertype). same as GSMP's Ethertype).
Length Length
This 2-byte unsigned integer indicates the total length of the This 2-byte unsigned integer indicates the total length of the
skipping to change at page 21, line 23 skipping to change at page 21, line 14
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
changes to the base GSMP adjacency protocol for implementing ANCP. changes to the base GSMP adjacency protocol for implementing ANCP.
The NAS will set the M-flag in the SYN message (signifying it is the The NAS will set the M-flag in the SYN message (signifying it is the
master). Once the adjacency is established, periodic adjacency master). Once the adjacency is established, periodic adjacency
messages (type ACK) are exchanged. The default ACK interval as messages (type ACK) are exchanged. The default ACK interval as
advertised in the adjacency messages is 10 sec for ANCP. It SHOULD advertised in the adjacency messages is 10 sec for ANCP. It SHOULD
be configurable and is an implementation choice. It is recommended be configurable and is an implementation choice. It is recommended
that both ends specify the same timer value. However, it is not that both ends specify the same timer value, in order to achieve this
necessary for the timer values to match. behavior both ends look at the timer values in the received (initial)
adjacency message and agree to use the higher of the two values.
That is, the node that receives a higher timer value than its own,
will reply in its subsequent adjacency messages (such as SYNACK, ACK)
with the higher timer value.
The GSMP adjacency message defined in [RFC3292] is extended for ANCP 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.
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
skipping to change at page 21, line 52 skipping to change at page 21, line 47
new connection requests. The DSLAM will try to re-establish the TCP new connection requests. The DSLAM will try to re-establish the TCP
connection and both sides will attempt to re-establish the adjacency. connection and both sides will attempt to re-establish the adjacency.
The handling defined above will need some modifications when ANCP The handling defined above will need some modifications when ANCP
graceful restart procedures are defined. These procedures will be graceful restart procedures are defined. These procedures will be
defined in a separate draft. defined in a separate draft.
5.3. Capability negotiation 5.3. Capability negotiation
The adjacency message as defined in [RFC3292] is extended to carry The adjacency message as defined in [RFC3292] is extended to carry
technology specific "Capability TLVs". Both the NAS and the access "Capability TLVs". Both the NAS and the access node will advertise
node will advertise supported capabilities in the originated supported capabilities in the originated adjacency messages. If a
adjacency messages. If a received adjacency message indicates received adjacency message indicates absence of support for a
absence of support for a capability that is supported by the capability that is supported by the receiving device, it will turn
receiving device, it will turn off the capability locally and will off the capability locally and will send an updated adjacency message
send an updated adjacency message with the capability turned off to with the capability turned off to match the received capability set.
match the received capability set. This process will eventually This process will eventually result in both sides agreeing on the
result in both sides agreeing on the minimal set of supported minimal set of supported capabilities. The adjacency will not come
capabilities. The adjacency will not come up unless the capabilities up unless the capabilities advertised by the controller and the
advertised by the controller and the controlled device match. controlled device match.
After initial synchronization, if at anytime a capability mismatch is After initial synchronization, if at anytime a capability mismatch is
detected, the adjacency will be brought down (RSTACK will be detected, the adjacency will be brought down (RSTACK will be
generated by the device detecting the mismatch), and synchronization generated by the device detecting the mismatch), and synchronization
will be re-attempted. will be re-attempted.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Sub | Message Type | Timer |M| Code | | Ver | Sub | Message Type | Timer |M| Code |
skipping to change at page 22, line 45 skipping to change at page 22, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Receiver Instance | | Partition ID | Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tech Type | # of TLVs | Total Length | | Tech Type | # of TLVs | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Capability TLVs ~ ~ Capability TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Figure 8
The format of capability TLV is: The format of capability TLV is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Type | Capability Length | | Capability Type | Capability Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Capability Data ~ ~ Capability Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Capability TLV Figure 9: Capability TLV
The Tech Type field type indicates the technology to which the The Tech Type field type indicates the technology to which the
capability extension applies. For access node control in case of DSL capability extension applies. For access node control in case of DSL
networks, new type "DSL" is proposed. The value for this field is networks, new type "DSL" is proposed. The value for this field is
0x05. This is the first available value in the range that is not 0x05. This is the first available value in the range that is not
currently allocated. It will need to be reserved with IANA. currently allocated. It will need to be reserved with IANA.
Capability length is the number of actual bytes contained in the Capability length is the number of actual bytes contained in the
value portion of the TLV. The TLV is padded to a 4-octet alignment. value portion of the TLV. The TLV is padded to a 4-octet alignment.
Therefore, a TLV with no data will contain a zero in the length field Therefore, a TLV with no data will contain a zero in the length field
skipping to change at page 24, line 23 skipping to change at page 24, line 23
Length (in bytes) : 0 Length (in bytes) : 0
Capability Data : NULL Capability Data : NULL
5.4. GSMP Message Extensions for Access Node Control 5.4. GSMP Message Extensions for Access Node Control
5.4.1. General Extensions 5.4.1. General Extensions
Extensions to GSMP messages for various use-cases of "Access Node Extensions to GSMP messages for various use-cases of "Access Node
Control" mechanism are defined in sections Section 5.4.2 to Control" mechanism are defined in sections Section 5.4.2 to
Section 5.4.5. However, sub-sections Section 5.4.1.1 below define Section 5.4.4. However, sub-sectionSection 5.4.1.1 below defines
extensions to GSMP that have general applicability. extensions to GSMP that have general applicability and section
Section 5.4.5 introduces anothor messaging principle and additional
general purpose TLVs that could be used to develop new use cases in
future.
5.4.1.1. Extension TLV 5.4.1.1. Extension TLV
In order to provide flexibility and extensibility certain GSMP In order to provide flexibility and extensibility certain GSMP
messages such as "PORT MANAGEMENT" and "EVENT" messages defined in messages such as "PORT MANAGEMENT" and "EVENT" messages defined in
[RFC3292] have been modified to include an extension block that [RFC3292] have been modified to include an extension block that
follows a TLV structure. Individual messages in the following follows a TLV structure. Individual messages in the following
sections describe the usage and format of the extension block. sections describe the usage and format of the extension block.
All Extension TLVs will be designated as follow: All Extension TLVs will be designated as follow:
skipping to change at page 24, line 46 skipping to change at page 25, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ Extension Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Extension TLV Figure 10: Extension TLV
x: Reserved Flags x: Reserved Flags
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
skipping to change at page 26, line 22 skipping to change at page 26, line 36
Not all the fields in GSMP Event message are applicable to ANCP. The Not all the fields in GSMP Event message are applicable to ANCP. The
fields that are not applicable MUST be set to zero by the ANCP sender fields that are not applicable MUST be set to zero by the ANCP sender
and ignored by the ANCP receiver. The fields in the PORT UP and PORT and ignored by the ANCP receiver. The fields in the PORT UP and PORT
DOWN messages to be set by the ANCP sender, and corresponding DOWN messages to be set by the ANCP sender, and corresponding
handling by the ANCP receiver is described below. handling by the ANCP receiver is described below.
The version field MUST be set to 3, and the sub field MUST be set to The version field MUST be set to 3, and the sub field MUST be set to
1. As defined in [RFC3292], the one byte Message Type field MUST be 1. As defined in [RFC3292], the one byte Message Type field MUST be
set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event set to 80 for PORT UP Event message, and to 81 for PORT DOWN Event
Message. The 8 bit Code field MUST be set to 0. The 4 bit Result Message. The 12 bit Code field MUST be set to 0. The 4 bit Result
field MUST be set to 0 (signifying Ignore.) If a PORT UP message field MUST be set to 0 (signifying Ignore.) If a PORT UP message
with a Result field set to 0 is received by the NAS and the NAS is with a Result field set to 0 is received by the NAS and the NAS is
able to process the message correctly, the NAS MUST NOT generate any able to process the message correctly, the NAS MUST NOT generate any
ANCP message in response to the PORT UP. If the PORT UP message ANCP message in response to the PORT UP. If the PORT UP message
received cannot be processed correctly by the NAS (e.g. the message received cannot be processed correctly by the NAS (e.g. the message
is malformed) the NAS MAY respond with an ANCP Error Message (TBD) is malformed) the NAS MAY respond with an ANCP Error Message (TBD)
containing the reason of the failure. The 24-bit Transaction containing the reason of the failure. The 24-bit Transaction
Identifier field MUST be set to 0. The "I" bit and the SubMessage Identifier field MUST be set to 0. The "I" bit and the SubMessage
field MUST be set to 1 to signify no fragmentation. The Length field field MUST be set to 1 to signify no fragmentation. The Length field
is two bytes and MUST contain the length of the message (including is two bytes and MUST contain the length of the message (including
skipping to change at page 27, line 41 skipping to change at page 28, line 31
+ Label + + Label +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ Extension Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 Figure 11
The format of the "Extension Value" field for Tech Type "DSL" is as The format of the "Extension Value" field for Tech Type "DSL" is as
follows : follows :
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Extension Value Figure 12: Extension Value
The "Extension Value" contains one or more TLVs to identify a DSL The "Extension Value" contains one or more TLVs to identify a DSL
line and define its characteristics. A TLV can consist of multiple line and define its characteristics. A TLV can consist of multiple
sub-TLVs. First 2 byte of the "Extension Value" contains the number sub-TLVs. First 2 byte of the "Extension Value" contains the number
of TLVs that follow. The next 2 bytes contain the total length of of TLVs that follow. The next 2 bytes contain the total length of
the TLVs carried in the extension block in bytes (existing "Block the TLVs carried in the extension block in bytes (existing "Block
Length" field in the GSMP message is limited to 255 bytes and is not Length" field in the GSMP message is limited to 255 bytes and is not
sufficient). sufficient).
General format of a TLV is : General format of a TLV is :
skipping to change at page 28, line 37 skipping to change at page 29, line 20
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Value ~ ~ Value ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: General TLV Figure 13: General TLV
The value field in each TLV is padded to a 4-octet alignment. The The value field in each TLV is padded to a 4-octet alignment. The
Length field in each TLV contains the actual number of bytes in the Length field in each TLV contains the actual number of bytes in the
TLV (not including the padding if present). If a TLV is not TLV (not including the padding if present). If a TLV is not
understood by the NAS, it is silently ignored. Currently defined understood by the NAS, it is silently ignored. Currently defined
types start from 0x01. types start from 0x01.
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
skipping to change at page 36, line 49 skipping to change at page 37, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Flags | Flow Control Flags | | Event Flags | Flow Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Extension Value ~ ~ Extension Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 Figure 14
The format of the "Extension Value" field is as follows: The format of the "Extension Value" field is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of TLVs | Extension Block length (bytes) | | # of TLVs | Extension Block length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TLVs ~ ~ TLVs ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Extension Value Figure 15: Extension Value
The "Extension Value" field contains one or more TLVs containing DSL The "Extension Value" field contains one or more TLVs containing DSL
line identifier and desired service attributes of the the DSL line. line identifier and desired service attributes of the the DSL line.
First 2 byte of the "Extension Value" contains the number of TLVs First 2 byte of the "Extension Value" contains the number of TLVs
that follow. The next 2 bytes contain the total length of the that follow. The next 2 bytes contain the total length of the
extension block in bytes (existing "Block Length" field in the GSMP extension block in bytes (existing "Block Length" field in the GSMP
message is limited to 255 bytes and is not sufficient). message is limited to 255 bytes and is not sufficient).
General format of a TLV is: General format of a TLV is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Value ~ ~ Value ~
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: General TLV Figure 16: General TLV
The value field is padded to a 4-octet alignment. The Length field The value field is padded to a 4-octet alignment. The Length field
in each TLV contains the actual number of bytes in the TLV (not in each TLV contains the actual number of bytes in the TLV (not
including the padding if present). If a TLV is not understood by the 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 Section 5.4.1. Aggregation Circuit-ID") as defined in section Section 5.4.1.
Following TLVs can appear in this message: Following TLVs can appear in this message:
o Type (Access-Loop-Circuit-ID = 0x01) : defined in section o Type (Access-Loop-Circuit-ID = 0x01) : defined in section
skipping to change at page 38, line 18 skipping to change at page 38, line 48
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 : (up to 64 bytes) Length : (up to 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).
In future, more TLVs MAY be defined for individual service In future, more TLVs MAY be defined for individual service
attributes of a DSL line (e.g. rates, interleaving delay, attributes of a DSL line (e.g. rates, interleaving delay,
multicast channel entitlement access-list etc). multicast channel entitlement access-list etc)
5.4.3.1. Provisioning Message
The Provisioning message is sent by the NAS to the AN to provision
information in the AN. This message can be used to provision global
scope information on the Access Node.
The Message Type for the Provisioning message is 93.
The NAS sending the Provisioning message MUST set the Result field to
0x00.
The NAS MUST populate the ANCP Transaction Identifier field with a
distinct non-zero, linearly incrementing value for each request per
adjacency, as described in Section 5.4.5 .
The ANCP Provisioning message payload MAY contain different TLVs,
like for example Service-Profile-Name TLV. The Service-Profile-Name
TLV MAY appear zero, one or multiple times.
On receipt of the Provisioning message, the AN MUST:
o ignore the Result field
o if the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any
response.
5.4.4. OAM Extensions 5.4.4. OAM Extensions
GSMP "Port Management" message (type 32) SHOULD be used by the NAS to GSMP "Port Management" message (type 32) SHOULD be used by the NAS to
trigger access node to run a loopback test on the local loop. The trigger access node to run a loopback test on the local loop. The
message format is defined in section Section 5.4.2. The version message format is defined in section Section 5.4.2. The version
field SHOULD be set to 3 and sub-version field SHOULD be set to 1. field SHOULD be set to 3 and sub-version field SHOULD be set to 1.
The remaining fields in the GSMP header have standard semantics. The The remaining fields in the GSMP header have standard semantics. The
function type used in the request message SHOULD be set to "remote function type used in the request message SHOULD be set to "remote
loopback" (type = 0x09). The port, "port session number", "event loopback" (type = 0x09). The port, "port session number", "event
skipping to change at page 41, line 29 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. Multicast Extensions 5.4.5. Additional GMSP Extensions for future use cases
The format of the ANCP Multicast message starts with the common GSMP GSMP protocol defined in [RFC3292] allows for two messaging
header as in the case of the existing ANCP implementation. Following principles in case of Request/Response interaction:
is the format of this header:
0 1 2 3 o The same message type used for both request message and response
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 message where result field and code field settings are used to
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ differentiate between request and response messages;
| Vers | Sub | Message Type | Result| Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Message Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: ANCP Header o Two different message types for request message and response
The Result field takes one of the values defined in Section 5. messages.
The Transaction Identifier field is used to distinguish between First message principle has been adopted for use cases defined in
request messages and to associate a response message to a request. sections Section 5.4.2 to Section 5.4.4, the purpose of this section
Applications that require such response correlation MUST set the is to specify the second type of approach in order to allow the use
Transaction Identifier to a value in the range (1, 2^24 - 1). When of this message principle for the development of future use cases.
used in this manner, the Transaction Identifier sequencing MUST be
maintained independently for each ANCP adjacency and per message In the new message paradigm different message types are used as ANCP
type. Furthermore, it SHOULD be incremented linearly for each new Request Message and ANCP Response Message: the format of a generic
message of the given type, cycling back to 1 after running the full ANCP message starts with the common GSMP header as in the case of the
range. Message types not requiring response message correlation existing ANCP implementation, but the Result field is set to Ignore
SHOULD set the Transaction Id field to 0x0. In the event of an ANCP in order to instruct the receipt to ignore this field and follow the
transport protocol failure, all pending ANCP messages destined to the procedures specified for the received message type. The Transaction
disconnected recipient can be discarded until the transport is re- Identifier field is used to distinguish between request messages and
established following which the Transaction Identifier is re- to associate a response message to a request. Applications that
initialized. require such response correlation MUST set the Transaction Identifier
to a value in the range (1, 2^24 - 1). When used in this manner, the
Transaction Identifier sequencing MUST be maintained independently
for each ANCP adjacency and per message type. Furthermore, it SHOULD
be incremented linearly for each new message of the given type,
cycling back to 1 after running the full range. Message types not
requiring response message correlation SHOULD set the Transaction Id
field to 0x0. In the event of an ANCP transport protocol failure,
all pending ANCP messages destined to the disconnected recipient can
be discarded until the transport is re- established following which
the Transaction Identifier is re- initialized.
The value of the Transaction Identifier in a Response message MUST be The value of the Transaction Identifier in a Response message MUST be
set to that of the respective Request message. This allows the set to that of the respective Request message. This allows the
Requester to correlate the Response to the original Request. The Requester to correlate the Response to the original Request. The
Transaction Identifier is not used in ANCP adjacency messages. Also, Transaction Identifier is not used in ANCP adjacency messages. Also,
other ANCP applications not requiring it SHOULD set the Transaction other ANCP applications not requiring it SHOULD set the Transaction
Identifier to 0x0 in their messages. Identifier to 0x0 in their messages.
All TLVs within the ANCP message have to be 32 bit aligned, and when All TLVs within the ANCP message have to be 32 bit aligned, and when
necessary padded with 0s to the 32 bit boundary. The padding is not necessary padded with 0s to the 32 bit boundary. The padding is not
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
Multicast 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 (0x10) is intended to be a general well known TLV
allowing the representation of different types of objects. Its use allowing the representation of different types of objects. Its use
is not restricted to any specific Message Type. 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 (0x10) indicating the type of target being addressed.
Numbers TBC. Tentative 0x1000 for single Access-Port. Tentative 0x1000 for 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.
skipping to change at page 45, line 47 skipping to change at page 47, line 5
Error Message Length: Error Message Length:
Contains the length of an optional error message or 0 if Contains the length of an optional error message or 0 if
none. none.
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.
5.4.5.2. Multicast Replication Control Message
The Multicast Replication Control Message Type 0x90 (TBC) is sent by
the NAS to the AN with a directive to either add (join) or delete
(leave) one or more multicast flows on a target object identified in
the content of the message. When a response is needed an AN MUST use
the Multicast Status message to convey the outcome of the directive;
this message type is covered in Section 5.4.5.3.
The sender of a Multicast Replication Control message MUST set the
Result field to 0x00 meaning "Ignore". The sender MUST populate the
ANCP Transaction Identifier field with a distinct non-zero, linearly
incrementing value for each Request per adjacency, as described in
Section 5.4.5 .
The ANCP Multicast Replication Control message payload contains the
following TLVs:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Target TLV | Length of Target-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value = Target-Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Length of Command Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value = Command Info ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Target:
See Section 5.4.5.1.1. The Target TLV (0x10) can only feature
once in a Multicast Replication Control Message. Only one such
TLV is allowed in this message type.
Length of Target-Info:
See Section 5.4.5.1.1
Target Info:
See Section 5.4.5.1.1
Command TLV:
The Command TLV (0x11) contains the multicast flow
directive(s) for the target and any additional parameters
passed via sub-TLVs. See Section 5.4.5.1.2
Length of Command Info:
Includes sub-TLVs. See Section 5.4.5.1.2
Command Info:
Command information as defined in section
Section 5.4.5.1.2.
The contents of the Command TLV for the Multicast Replication Control
Message are defined to be as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |R O M Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Multicast Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++++++++|
| Addr Family | Encoding Type | Multicast Flow Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++-+
Command Code:
Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
All.
Command Length:
Length in bytes of each Command including multicast flow
address, but excluding the Command Code header and flags.
Flags:
8 bit General purpose Flag field. Currently the following
flags are defined:
R -
Resource Admitted Flag. Set to 1 in an add
command to indicate that the flow resources have
been reserved by admission control, 0 otherwise.
Not used in delete command.
O -
Flow Accounting. When set in add command
indicates that byte accounting for the flow is to
commence.
M -
When set indicates that multicast flow is SSM and
the address-family-element set MUST specify the
source and group addresses. When not set
indicates that multicast flow is ASM and address-
family-element MUST specify the group address,
and the Source Address field is to be omitted.
Address Family:
The address family used
The unicast source address/mask follows the format defined in
[IANAAEA]
Encoded-Unicast-address: Takes the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
Encoded-Unicast-address: Takes the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++++++++++
Encoding Type:
The type of encoding used within a specific Address Family.
The value `0' is reserved for this field, and represents
the native encoding of the Address Family.
The address as represented by the given Address Family and
Encoding Type.
Address:
The address as represented by the given Address Family and
Encoding Type.
The padding will be done after both addresses so that it is 32-bit
aligned. As an example for IPv4:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmdCode=0x01 |0 0 1 Flags | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 0x1| Enc Type 0x0 | Src Address first 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address last 2 bytes | AddrFamily 0x1| Enc Type 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above example, no padding is required.
A received Multicast Replication Control Message containing an
unrecognized Target TLV MUST be communicated to the sender as an
error in a Multicast Status Message indicating the "Unrecognised port
Type - 0x04" error. The reception of a Multicast Replication Control
Message, or any ANCP message, that is found to have mandatory TLVs
missing is to be addressed as part of a ANCP base protocol mechanism
yet to be defined.
Each Multicast Replication Control Message may contain one or more
command directives, each encapsulated by their own Command TLVs. The
sender MUST use separate Command TLVs for each distinct multicast
flow. When successive commands relate to a given Target and flow,
the state of features controlled or affected by flags as well as by
optional attributes received in the Multicast Replication Control
message, are to be interpreted as replacing any such previous state
for that port and flow. As an example, successive Multicast
Replication Control messages containing add commands for a given port
and flow, but differing in the accounting flag setting should be
interpreted as affecting the state of the accounting feature.
The recipient of a Multicast Replication Control message is to run an
implicit directive numbering across the multiple directives in the
message. The numbering is to start from 0x01 for each directive in a
given ANCP Multicast Replication Control message, and be restarted
for subsequent messages. The recipient MUST process the directives
in the order of reception, and use the derived directive number in
any response messages, besides the Transaction ID.
The processing/execution of multiple directives contained in a single
Multicast Control message MUST be interrupted at the first error, and
the remaining commands in the Multicast Replication Control message
discarded. In such a case a Multicast Status message MUST be sent
indicating the command number that resulted in the error along with
the error code.
When the strict sequenced processing of the directives in a single
Multicast Control message is not required the directives MUST be
distributed across separate Multicast Replication Control messages.
Each command directive is equipped with an 8-bit Flags field that
allows specification of Multicast ASM or SSM modes of operation, and
an indication of other features or conditions attached to this
command (e.g. To enable accounting for the flow, etc). Unassigned
flags are reserved for future use, and could in the future be subject
of the capability negotiation. When receiving a Multicast
Replication Control Message containing an unrecognized Flag set (to
1), a recipient MUST interpret it as an error, and generate an
Multicast Status message indicating the error.
The multicast flow subject to the command is specified by means of
one or two well known Address Family designators ([IANAAEA]), the
IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02). When
the M flag is set the two Address-Family tuples MUST be present in
the strict order specifying the multicast flow source and group
respectively. When the M flag is cleared only one Address-Family is
allowed, specifying the multicast flow.
For future extensibility, each command may also have additional TLVs
appended following the command and multicast flow information
(referred to as "TLVs" in the message format above). Unrecognized
TLVs SHOULD be silently discarded. The figure below is an example of
a Multicast Replication Control message that would result in a swap
from multicast SSM flows 192.0.2.1, 233.252.0.2, to 192.0.2.2,
233.252.0.3 on the Target identified by the "Access Loop Circuit ID":
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=90 | 0x02 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Target 0x1000 | Target TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access-Loop-Circuit-ID 0x0001 | Circuit-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Loop Circuit ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Command TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x02 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow : 233.252.0.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
| Type = Command-TLV | Command-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cmd Code=0x01 |0 0 1 | Command Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Source: 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AddrFamily 01 | EncType 0x0 | Mcast Flow: 233.252.0.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.5.3. Multicast Status Message
The Multicast Status Message (Message Type 0x91 - TBC) is sent by the
AN to the NAS in response to a Multicast Replication Control Message
and its command directives. A Multicast Status message MUST use the
same ANCP Transaction ID as that in the original Multicast
Replication Control Message. The Success or Failure status is
reported in the Result field of the ANCP header as described in
Section 5.4.5.
A Multicast Status Message indicating Success SHOULD simply consist
only of the base ANCP header with no body, however the message MAY
contain one or more TLVs that are meant to communicate any relevant
information to an application. The payload of a Multicast Status
Message indicating Failure MUST contain an Status-Info TLV (0x12), as
defined in Section 5.4.5.1.3, as its first TLV and SHOULD be followed
by the Target TLV and Port-info. Other TLVs MAY be present. A
Multicast Status message indicating Failure MUST be sent whenever a
Multicast Control message cannot be fulfilled or results in an
execution error. The Cmnd Nmbr parameter in the Status-Info TLV
contained by the Multicast Status Message is to indicate the number
of the command in the Multicast Replication Control Message that
resulted in an error.
0x00 - Success
0x01 - Malformed message
0x02 - Command not supported
0x03 - Flag set but not supported
0x04 - Unrecognized Target
0x05 - Unsupported Address Family
0x06 - Malformed flow address
0x07 - No resources
0x08 - Unknown Target
0x09 - Target down
0x0a - Configuration error (such as Port not enabled for
multicast)
0x0b - Multicast flow does not exist
0x0c - Unsupported address encoding
0x0d - Additional info needed to execute command (payload MAY
contain an indication of the expected info)
0x0e - Multicast flow count exceeded
0x0f - M Flag set, but no IP Source address provided
0x10 - Transaction-id out of sequence
An example of a failure message for an invalid address, including the
Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV
padding, is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Sub |MessageType=91 | 0x4 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partition ID | Transaction Identifier = 0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| SubMessage Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status-info-TLV=0x12 | Status-TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Cmd Number | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4) if Length > 0 |
+---------------------------------------------------------------+
| Target TLV=0x10 | Target-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Loop ID type | Access-Loop ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| circuit ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. ATM-specific considerations 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")
corresponding to a subscriber. The "Access loop circuit-ID" has no corresponding to a subscriber. The "Access loop circuit-ID" has no
skipping to change at page 54, line 45 skipping to change at page 48, line 14
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. 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 | Reference | | Message | Number | Source |
+-------------------------------+--------+---------------+ +--------------+--------+---------------+
| Multicast Replication Control | 90 | This document | | Provisioning | 93 | This document |
| Multicast Status | 91 | This document | +--------------+--------+---------------+
+-------------------------------+--------+---------------+
This document defines the following modification to the Global Switch This document defines the following modification to the General
Management Protocol version 3 (GSMPv3) Result Type Name Space Switch Management Protocol version 3 (GSMPv3) Result Type Name Space
registry: registry:
+--------------+------------------------+---------------+ +--------------+------------------------+---------------+
| Result Value | Result Type Name | Reference | | Result Value | Result Type Name | Reference |
+--------------+------------------------+---------------+ +--------------+------------------------+---------------+
| 0 | Ignore (from Reserved) | This document | | 0 | Ignore (from Reserved) | This document |
+--------------+------------------------+---------------+ +--------------+------------------------+---------------+
This document defines the following addition to the GSMPv3 Message This document defines the following addition to the GSMPv3 Message
Function Name Space registry [editor's note GMSPv3 did not define a Function Name Space registry [editor's note GMSPv3 did not define a
skipping to change at page 56, line 8 skipping to change at page 49, line 31
| 0x0506 | DSL line status training | This | | 0x0506 | DSL line status training | This |
| | | document | | | | document |
| 0x507 | DSL line integrity error | This | | 0x507 | DSL line integrity error | This |
| | | document | | | | document |
| 0x0508 | DSLAM resource not | This | | 0x0508 | DSLAM resource not | This |
| | available | document | | | available | document |
| 0x509 | Invalid test parameter | This | | 0x509 | Invalid test parameter | This |
| | | document | | | | document |
+-------------------------+----------------------------+------------+ +-------------------------+----------------------------+------------+
This document defines a new ANCP Version Space registry. The initial
entry is as follows:
+--------------------+-------------------+---------------+
| ANCP Version Value | ANCP Version Name | Reference |
+--------------------+-------------------+---------------+
| 3 | ANCP Version | This document |
+--------------------+-------------------+---------------+
This document defines a new ANCP Version Space registry. The initial
entry is as follows:
+------------------------+-----------------------+---------------+
| ANCP Sub-Version Value | ANCP Sub-Version Name | Reference |
+------------------------+-----------------------+---------------+
| 1 | ANCP Sub-Version | This document |
+------------------------+-----------------------+---------------+
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 | Tech Type Name | Reference |
| Value | | | | Value | | |
+----------------+-----------------------------------+--------------+ +----------------+-----------------------------------+--------------+
| 0x00 | Extension block not in use | This | | 0x00 | Extension block not in use | This |
| | | document | | | | document |
| 0x01 - 0x04 | Already in use by various | This | | 0x01 - 0x04 | Already in use by various | This |
skipping to change at page 56, line 30 skipping to change at page 50, line 24
| | | document | | | | document |
| 0x06 - 0xFE | Reserved | This | | 0x06 - 0xFE | Reserved | This |
| | | document | | | | document |
| 0xFF | Base Specification Use | This | | 0xFF | Base Specification Use | This |
| | | document | | | | document |
+----------------+-----------------------------------+--------------+ +----------------+-----------------------------------+--------------+
This document defines a new ANCP Status-Info Result Code registry. This document defines a new ANCP Status-Info Result Code registry.
The initial entries are as follows: The initial entries are as follows:
+-----------------------------------------------+-------+-----------+ +--------------------------------+-------+---------------+
| Result Code | Value | Reference | | Result Code | Value | Reference |
+-----------------------------------------------+-------+-----------+ +--------------------------------+-------+---------------+
| Success | 0x00 | This | | Success | 0x00 | This document |
| | | document | | Malformed message | 0x01 | This document |
| Malformed message | 0x01 | This | | Command not supported | 0x02 | This document |
| | | document | | Unrecognized Target | 0x04 | This document |
| Command not supported | 0x02 | This | | No resources | 0x07 | This document |
| | | document | | Unknown Target | 0x08 | This document |
| Flag set but not supported | 0x03 | This | | Target down | 0x09 | This document |
| | | document | | Transaction-id out of sequence | 0x010 | This document |
| Unrecognized Target | 0x04 | This | +--------------------------------+-------+---------------+
| | | document |
| Unsupported Address Family | 0x05 | This |
| | | document |
| Malformed flow address | 0x06 | This |
| | | document |
| No resources | 0x07 | This |
| | | document |
| Unknown Target | 0x08 | This |
| | | document |
| Target down | 0x09 | This |
| | | document |
| Configuration error (such as Port not enabled | 0x0a | This |
| for multicast) | | document |
| Multicast flow does not exist | 0x0b | This |
| | | document |
| Unsupported address encoding | 0x0c | This |
| | | document |
| Additional info needed to execute command | 0x0d | This |
| (payload MAY contain an indication of the | | document |
| expected info) | | |
| Multicast flow count exceeded | 0x0e | This |
| | | document |
| M Flag set, but no IP Source address provided | 0x0f | This |
| | | document |
| Transaction-id out of sequence | 0x010 | This |
| | | document |
+-----------------------------------------------+-------+-----------+
This document defines a new ANCP Command Code registry. The initial 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 |
| Add | 0x01 | This document |
| Delete | 0x02 | This document |
| Delete All | 0x03 | 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 document |
| Access-Loop-Remote-Id | 0x02 | This document | | Access-Loop-Remote-Id | 0x02 | This document |
skipping to change at page 60, line 9 skipping to change at page 53, line 9
+--------------------------------------------+--------+-------------+ +--------------------------------------------+--------+-------------+
7. Security Considerations 7. Security Considerations
Security of the ANCP protocol is discussed in [ANCP-SEC] Security of the ANCP protocol is discussed in [ANCP-SEC]
8. Acknowledgements 8. 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 Peter Arberg, Josef Froehler, Derek Harkness, the inputs provided by Wojciech Dec, Peter Arberg, Josef Froehler,
Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel Platnic, Tom Taylor Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, Michel
and the work done by Philippe Champagne, Wojciech Dec and Stefaan De Platnic and Tom Taylor.
Cnodder regarding multicast extensions.
9. References 9. References
9.1. Normative References 9.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.
skipping to change at page 60, line 38 skipping to change at page 53, line 37
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 9.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-08.txt, , February 2009. draft-ietf-ancp-framework-10.txt, work in progress,
May 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-07.txt work in progress, draft-ietf-ancp-security-threats-08.txt work in progress,
March 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.
[G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair [G.988.2] "ITU-T recommendation G.998.2, Ethernet-based multi-pair
bonding,", 2005. bonding,", 2005.
[IANAAEA] "http://www.iana.org/assignments/address-family-numbers",
2005.
[TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service [TR-058] Elias, M. and S. Ooghe, "DSL Forum TR-058, Multi-Service
Architecture & Framework Requirements", September 2003. Architecture & Framework Requirements", September 2003.
[TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution - [TR-059] Anschutz, T., "DSL Forum TR-059, DSL Evolution -
Architecture Requirements for the Support of QoS-Enabled Architecture Requirements for the Support of QoS-Enabled
IP Services", September 2003. IP Services", September 2003.
[TR-092] "DSL Forum TR-092, Broadband Remote access server [TR-092] "DSL Forum TR-092, Broadband Remote access server
requirements document", 2005. requirements document", 2005.
 End of changes. 47 change blocks. 
535 lines changed or deleted 170 lines changed or added

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