RFC 6320
Protocol for Access Node Control Mechanism in Broadband Networks
4. Generally Useful ANCP Messages and TLVs
This section defines two messages and a number of TLVs that could be useful in multiple capabilities. In some cases, the content is under-specified, with the intention that particular capabilities spell out the remaining details.4.1. Provisioning Message
The Provisioning message is sent by the NAS to the AN to provision information of global scope (i.e., not associated with specific access lines) on the AN. The Provisioning message has the format shown in Figure 9. Support of the Provisioning message is OPTIONAL unless the ANCP agent claims support for a capability that requires its use. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/IP Encapsulating Header (Section 3.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANCP General Message Header | + (Section 3.6.1) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Format of the Provisioning Message The message header field settings given below are REQUIRED in the Provisioning message. The remaining message header fields MUST be set as specified in Section 3.6.1. Which TLVs to carry in the Provisioning message is specified as part of the specification of the capabilities that use that message. The Provisioning message MAY be used to carry data relating to more than one capability at once, assuming that the capabilities concerned can coexist and have all been negotiated during adjacency establishment. Message Type: MUST be set to 93. Result: MUST be set to 0x0 (Ignore). Result Code: MUST be set to zero.
Transaction ID: MUST be populated with a non-zero value chosen in
the manner described in Section 3.6.1.6.
If the AN can process the message successfully and accept all the
provisioning directives contained in it, the AN MUST NOT send any
response.
Unless otherwise specified for a particular capability, if the AN
fails to process the message successfully it MUST send a Generic
Response message (Section 4.2) indicating failure and providing
appropriate diagnostic information.
4.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.
Support of the Generic Response message, both as sender and as
receiver, is REQUIRED for all ANCP agents, regardless of what
capabilities they support.
The AN or NAS MAY send a Generic Response message indicating a
failure condition independently of a specific request before closing
the adjacency as a consequence of that failure condition. In this
case, the sender MUST set the Transaction ID field in the header and
the Message Type field within the Status-Info TLV to zeroes. The
receiver MAY record the information contained in the Status-Info TLV
for management use.
The format of the Generic Response message is shown in Figure 10.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/IP Encapsulating Header (Section 3.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANCP General Message Header | + (Section 3.6.1) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access line identifying TLV(s) | + (copied from original request) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status-Info TLV | ~ (Section 4.5) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE: TLVs MAY be in a different order from what is shown in this figure. Figure 10: Structure of the Generic Response Message This document specifies the following header fields. The remaining fields in the ANCP general message header MUST be set as specified in Section 3.6.1. Message Type: MUST be set to 91. Result: MUST be set to 0x3 (Success) or 0x4 (Failure). Result Code: MUST be set to zero for success or an appropriate non- zero value for failure. Transaction ID: MUST be copied from the message to which this message is a response. If the original request applied to a specific access line or set of lines, the TLVs identifying the line(s) and possibly the user MUST be copied into the Generic Response message at the top level. The Status-Info TLV MAY be present in a success response, to provide a warning as defined for a specific request message type. It MUST be present in a failure response. See Section 4.5 for a detailed description of the Status-Info TLV. The actual contents will depend on the request message type this message is responding to and the value of the Result Code field.
To prevent an infinite loop of error responses, if the Generic Response message is itself in error, the receiver MUST NOT generate an error response in return.4.3. Target TLV
Type: 0x1000 to 0x1020 depending on the specific content. Only 0x1000 has been assigned in this specification (see below). Support of any specific variant of the Target TLV is OPTIONAL unless the ANCP agent claims support for a capability that requires its use. Description: The Target TLV (0x1000 - 0x1020) is intended to be a general means to represent different types of objects. Length: Variable, depending on the specific object type. Value: Target information as defined for each object type. The Value field MAY consist of sub-TLVs. TLV Type 0x1000 is assigned to a variant of the Target TLV representing a single access line and encapsulating one or more sub- TLVs identifying the target. Figure 11 is an example illustrating the TLV format for a single port identified by an Access-Loop- Circuit-ID TLV (0x0001) (Section 5.1.2.1). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = 0x1000 |Length = Circuit-ID Length + 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access-Loop-Circuit-ID=0x0001 | Circuit-ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access Loop Circuit ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Example of Target TLV for Single Access Line4.4. Command TLV
Type: 0x0011 Description: The Command TLV (0x0011) is intended to be a general means of encapsulating one or more command directives in a TLV- oriented message. The semantics of the command can be specified for each message type using it. That is, the specification of
each message type that can carry the Command TLV is expected to
define the meaning of the content of the payload, although re-use
of specifications is, of course, permissible when appropriate.
Support of any specific variant of the Command TLV is OPTIONAL
unless the ANCP agent claims support for a capability that
requires its use.
Length: Variable, depending on the specific contents.
Value: Command information as defined for each message type. The
field MAY include sub-TLVs. The contents of this TLV MUST be
specified as one "command" or alternatively a sequence of one or
more "commands", each beginning with a 1-byte Command Code and
possibly including other data following the Command Code. An IANA
registry has been established for Command Code values. This
document reserves the Command Code value 0 as an initial entry in
the registry.
4.5. Status-Info TLV
Name: Status-Info
Type: 0x0106
Description: The Status-Info-TLV is intended to be a general
container for warning or error diagnostics relating to commands
and/or requests. It is a supplement to the Result Code field in
the ANCP general header. The specifications for individual
message types MAY indicate the use of this TLV as part of
responses, particularly for failures. As mentioned above, the
Generic Response message will usually include an instance of the
Status-Info TLV. Support of the Status-Info TLV, both as sender
and as receiver, is REQUIRED for all ANCP agents, regardless of
what capabilities they support.
Length: Variable, depending on the specific contents.
Value: The following fixed fields. In addition, sub-TLVs MAY be
appended to provide further diagnostic information.
Reserved (8 bits): See Section 3.4 for handling of reserved
fields.
Msg Type (8 bits): Message Type of the request for which this TLV
is providing diagnostics.
Error Message Length (16 bits): Number of bytes in the error
message, excluding padding, but including the language tag and
delimiter. This MAY be zero if no error message is provided.
Error Message: Human-readable string providing information about
the warning or error condition. The initial characters of the
string MUST be a language tag as described in [RFC5646],
terminated by a colon (":"). The actual text string follows
the delimiter. The field is padded at the end with zeroes as
necessary to extend it to a 4-byte word boundary.
Section 3.6.1.4 provides recommendations for what TLVs to add in
the Status-Info TLV for particular values of the message header
Result Code field.
Figure 12 illustrates the Status-Info TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Msg Type | Error Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (padded to 4-byte boundary) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional sub-TLVs... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Status-Info TLV
5. Introduction to ANCP Capabilities for Digital Subscriber Lines
(DSLs)
DSL is a widely deployed access technology for Broadband Access for
Next Generation Networks. Specifications such as [TR-059], [TR-058],
and [TR-092] describe possible architectures for these access
networks. The scope of these specifications includes the delivery of
voice, video, and data services.
The next three sections of this document specify basic ANCP
capabilities for use specifically in controlling Access Nodes serving
DSL access (Tech Type = 0x05). The same ANs could be serving other
access technologies (e.g., Metro-Ethernet, Passive Optical
Networking, WiMax), in which case the AN will also have to support
the corresponding other-technology-specific capabilities. Those
additional capabilities are outside the scope of the present
document.
5.1. DSL Access Line Identification
Most ANCP messages involve actions relating to a specific access line. Thus, it is necessary to describe how access lines are identified within those messages. This section defines four TLVs for that purpose and provides an informative description of how they are used.5.1.1. Control Context (Informative)
Three types of identification are described in [TR-101] and provided for in the TLVs defined in this section: o identification of an access line by its logical appearance on the user side of the Access Node; o identification of an access line by its logical appearance on the NAS side of the Access Node; and o identification down to the user or host level as a supplement to access line identification in one of the other two forms. All of these identifiers originate with the AN control application, during the process of DSL topology discovery. The control application chooses which identifiers to use and the values to place into them on a line-by-line basis, based on AN configuration and deployment considerations. Aside from its use in ANCP signalling, access line identification is also used in DHCP ([RFC2131], [RFC3315]) transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR-101] requires the AN or NAS in this role to add access line identification in Option 82 (Information) ([RFC3046], with its IPv6 equivalent in [RFC4649]) to each DHCP request it forwards to the DHCP server. It is desirable for efficiency that the identification used in this signalling should be the same as the identification used in ANCP messages. From the point of view of ANCP itself, the identifiers are opaque. From the point of view of the AN control application, the syntax for the user-side access line identifier is the same as specified in Section 3.9.3 of [TR-101] for DHCP Option 82. The syntax for the ASCII form of the NAS-side access line identifier will be similar. Access line identification by logical appearance on the user side of the Access Node will always identify a DSL access line uniquely. Identification by the logical appearance on the NAS side of the Access Node is unique only if there is a one-to-one mapping between
the appearances on the two sides and no identity-modifying
aggregation between the AN and the NAS. In other cases, and in
particular in the case of Ethernet aggregation using the N:1 VLAN
model, the user-side access line identification is necessary, but the
NAS-side identification is potentially useful information allowing
the NAS to build up a picture of the aggregation network topology.
Additional identification down to the user or host level is intended
to supplement rather than replace either of the other two forms of
identification.
Sections 3.8 and 3.9 of [TR-101] are contradictory on this point.
It is assumed here that Section 3.9 is meant to be authoritative.
The user-level identification takes the form of an administered
string that again is opaque at the ANCP level.
The NAS control application will use the identifying information it
receives from the AN directly for some purposes. For examples, see
the introductory part of Section 3.9 of [TR-101]. For other
purposes, the NAS will build a mapping between the unique access line
identification provided by the AN, the additional identification of
the user or host (where provided), and the IP interface on a
particular host. For access lines with static IP address assignment,
that mapping could be configured instead.
5.1.2. TLVs for DSL Access Line Identification
This section provides a normative specification of the TLVs that ANCP
provides to carry the types of identification just described. The
Access-Loop-Circuit-ID TLV identifies an access line by its logical
appearance on the user side of the Access Node. Two alternatives,
the Access-Aggregation-Circuit-ID-ASCII TLV and the Access-
Aggregation-Circuit-ID-Binary TLV, identify an access line by its
logical appearance on the NAS side of the Access Node. It is
unlikely that a given AN uses both of these TLVs, either for the same
line or for different lines, since they carry equivalent information.
Finally, the Access-Loop-Remote-ID TLV contains an operator-
configured string that uniquely identifies the user on the associated
access line, as described in Sections 3.9.1 and 3.9.2 of [TR-101].
ANCP agents conforming to this section MUST satisfy the following
requirements:
o ANCP agents MUST be able to build and send the Access-Loop-
Circuit-ID TLV, the Access-Loop-Remote-ID TLV, and either the
Access-Aggregation-Circuit-ID-ASCII TLV or the Access-Aggregation-
Circuit-ID-Binary TLV (implementation choice), when passed the
associated information from the AN control application.
o ANCP agents MUST be able to receive all four TLV types, extract
the relevant information, and pass it to the control application.
o If the Access-Loop-Remote-ID TLV is present in a message, it MUST
be accompanied by an Access-Loop-Circuit-ID TLV and/or an Access-
Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-Circuit-ID-
Binary TLV with two VLAN identifiers.
The Access-Loop-Remote-ID TLV is not enough to identify an
access line uniquely on its own. As indicated above, an
Access-Aggregation-Circuit-ID-ASCII TLV or Access-Aggregation-
Circuit-ID-Binary TLV with two VLAN identifiers may or may not
identify an access line uniquely, but this is up to the control
application to decide.
o If the Access-Aggregation-Circuit-ID-ASCII TLV or Access-
Aggregation-Circuit-ID-Binary TLV is present in a message with
just one VLAN identifier, it MUST be accompanied by an Access-
Loop-Circuit-ID TLV.
5.1.2.1. Access-Loop-Circuit-ID TLV
Type: 0x0001
Description: A locally administered human-readable string generated
by or configured on the Access Node, identifying the corresponding
access loop logical port on the user side of the Access Node.
Length: Up to 63 bytes
Value: ASCII string
5.1.2.2. Access-Loop-Remote-ID TLV
Type: 0x0002
Description: An operator-configured string that uniquely identifies
the user on the associated access line, as described in Sections
3.9.1 and 3.9.2 of [TR-101].
Length: Up to 63 bytes Value: ASCII string5.1.2.3. Access-Aggregation-Circuit-ID-Binary TLV
Type: 0x0006 Description: This TLV identifies or partially identifies a specific access line by means of its logical circuit identifier on the NAS side of the Access Node. For Ethernet access aggregation, where a per-subscriber (stacked) VLAN can be applied (1:1 model as defined in [TR-101]), the TLV contains two value fields. Each field carries a 12-bit VLAN identifier (which is part of the VLAN tag defined by [IEEE802.1Q]). The first field MUST carry the inner VLAN identifier, while the second field MUST carry the outer VLAN identifier. When the N:1 VLAN model is used, only one VLAN tag is available. For the N:1 model, the Access-Aggregation-Circuit-ID-Binary TLV contains a single value field, which MUST carry the 12-bit VLAN identifier derived from the single available VLAN tag. In the case of an ATM aggregation network, where the DSLAM is directly connected to the NAS (without an intermediate ATM switch), the Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI) on the DSLAM uplink correspond uniquely to the DSL access line on the DSLAM. The Access-Aggregation-Circuit-ID- Binary TLV MAY be used to carry the VPI and VCI. The first value field of the TLV MUST carry the VCI, while the second value field MUST carry the VPI. Each identifier MUST be placed in the low-order bits of its respective 32-bit field, with the higher-order bits set to zero. The ordering of the bits of the identifier MUST be the same as when the identifier is transmitted on the wire to identify an Ethernet frame or ATM cell. The Access-Aggregation-Circuit-ID-Binary is illustrated in Figure 13. Length: 4 or 8 bytes Value: One or two 32-bit binary fields.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = 0x0006 | Length = 4 or 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Single VLAN Identifier, inner VLAN identifier, or VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer VLAN identifier or VPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: The Access-Aggregation-Circuit-ID-Binary TLV5.1.2.4. Access-Aggregation-Circuit-ID-ASCII TLV
Type: 0x0003 Description: This TLV transmits the ASCII equivalent of the Access- Aggregation-Circuit-ID-Binary TLV. As mentioned in the previous section, the AN control application will use a format similar to that specified in Section 3.9.3 of [TR-101] for the format of the "circuit-id". As an extension to the present document, the Access Node could convey to the NAS the characteristics (e.g., bandwidth) of the uplink on the Access Node. This TLV or the binary equivalent defined above then serves the purpose of uniquely identifying the uplink whose characteristics are being defined. The present document does not specify the TLVs needed to convey the uplink characteristics. Length: Up to 63 bytes Value: ASCII string6. ANCP-Based DSL Topology Discovery
Section 3.1 of [RFC5851] describes the requirements for the DSL Topology Discovery capability.6.1. Control Context (Informative)
The AN control application in the DSLAM requests ANCP to send a DSL- specific Port Up message to the NAS under the following circumstances: o when a new adjacency with the NAS is established, for each DSL loop that is synchronized at that time;
o subsequent to that, whenever a DSL access line resynchronizes; and
o whenever the AN control application wishes to signal that a line
attribute has changed.
The AN control application in the DSLAM requests ANCP to send a DSL-
specific Port Down message to the NAS under the following
circumstances:
o when a new adjacency with the NAS is established, for each DSL
loop that is provisioned but not synchronized at that time;
o whenever a DSL access line that is equipped in an AN but
administratively disabled is signaled as "IDLE"; and
o subsequent to that, whenever a DSL access line loses
synchronization.
The AN control application passes information to identify the DSL
loop to ANCP to include in the Port Up or Port Down message, along
with information relating to DSL access line attributes.
In the case of bonded copper loops to the customer premise (as per
DSL multi-pair bonding described by [G.998.1] and [G.998.2]), the AN
control application requests that ANCP send DSL-specific Port Up and
Port Down messages for the aggregate "DSL bonded circuit"
(represented as a single logical port) as well as the individual DSL
access lines of which it is comprised. The information relating to
DSL access line attributes that is passed by the AN control
application is aggregate information.
ANCP generates the DSL-specific Port Up or Port Down message and
transfers it to the NAS. ANCP on the NAS side passes an indication
to the NAS control application that a DSL Port Up or Port Down
message has been received along with the information contained in the
message.
The NAS control application updates its view of the DSL access line
state, performs any required accounting operations, and uses any
included line attributes to adjust the operation of its queuing/
scheduling mechanisms as they apply to data passing to and from that
DSL access line.
Figure 14 summarizes the interaction.
1. Home Access NAS Gateway Node -----------> --------------------------> DSL Port Up (Event message) Signal (default line parameters) 2. Home Access NAS Gateway Node -----------> --------------------------> DSL Port Up (Event message) Resynch (updated line parameters) 3. Home Access NAS Gateway Node -----------> --------------------------> Loss of Port Down (Event message) DSL Signal (selected line parameters) Figure 14: ANCP Message Flow for DSL Topology Discovery6.2. Protocol Requirements
The DSL topology discovery capability is assigned capability type 0x0001. No capability data is associated with this capability.6.2.1. Protocol Requirements on the AN Side
The AN-side ANCP agent MUST be able to create DSL-specific Port Up and Port Down messages according to the format specified in Section 6.3. The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Up and Port Down messages as they are specified in Section 6.4.6.2.2. Protocol Requirements on the NAS Side
The NAS-side ANCP agent MUST be able to receive and validate DSL- specific Port Up and Port Down messages according to the format specified in Section 6.3.
The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Up and Port Down messages as they are specified in Section 6.4.6.3. ANCP Port Up and Port Down Event Message Descriptions
The format of the ANCP Port Up and Port Down Event messages is shown in Figure 15. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/IP Encapsulating Header (Section 3.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANCP General Message Header | + (Section 3.6.1) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unused (20 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Tech Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of TLVs | Extension Block length (bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access line identifying TLV(s) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSL-Line-Attributes TLV | ~ (MANDATORY in Port Up, OPTIONAL in Port Down) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE: TLVs MAY be in a different order from what is shown in this figure. Figure 15: Format of the ANCP Port Up and Port Down Event Messages for DSL Topology Discovery See Section 3.6.1 for a description of the ANCP general message header. The Message Type field MUST be set to 80 for Port Up, 81 for Port Down. The 4-bit Result field MUST be set to zero (signifying Ignore). The 12-bit Result Code field and the 24-bit Transaction
Identifier field MUST also be set to zeroes. Other fields in the general header MUST be set a as described in Section 3.6. The five-word Unused field is a historical leftover. The handling of unused/reserved fields is described in Section 3.4. The remaining message fields belong to the "extension block", and are described as follows: Extension Flags (8 bits): The flag bits denoted by 'x' are currently unspecified and reserved. Message Type (8 bits): Message Type has the same value as in the general header (i.e., 80 or 81). Tech Type (8 bits): MUST be set to 0x05 (DSL). Reserved (8 bits): set as described in Section 3.4. # of TLVs (16 bits): The number of TLVs that follow, not counting TLVs encapsulated within other TLVs. Extension Block Length (16 bits): The total length of the TLVs carried in the extension block in bytes, including any padding within individual TLVs. TLVs: One or more TLVs to identify a DSL access line and zero or more TLVs to define its characteristics.6.4. Procedures
6.4.1. Procedures on the AN Side
The AN-side ANCP agent creates and transmits a DSL-specific Port Up or Port Down message when requested by the AN control application and presented with the information needed to build a valid message. It is RECOMMENDED that the Access Node use a dampening mechanism per DSL access line to control the rate at which state changes are communicated to the NAS. At the top level, the extension block within a DSL-specific Port Up or Port Down message MUST include TLVs from Section 5.1.2 to identify the DSL access line. TLVs presenting DSL access line attributes (i.e., the TLVs specified in Section 6.5) MUST be encapsulated within the DSL-Line-Attributes TLV. When the DSL-Line-Attributes TLV is present in a message, it MUST contain at least one such TLV and will generally contain more
than one. In the Port Up message, the DSL-Line-Attributes TLV MUST be present. In the Port Down message, the DSL-Line-Attributes TLV MAY be present.6.4.2. Procedures on the NAS Side
The NAS-side ANCP agent MUST be prepared to receive Port Up and Port Down messages for a given DSL access line or logical port at any time after negotiation of an adjacency has been completed. It is possible for two Port Up messages in succession to be received for the same DSL access line without an intervening Port Down message, and vice versa. The NAS-side ANCP agent SHOULD validate each message against the specifications given in Section 6.3 and the TLV specifications given in Sections 5.1.2 and 6.5. If it finds an error, it MAY generate a Generic Response message containing an appropriate Result Code value. If it does so, the message MUST contain copies of all of the identifier TLVs from Section 5.1.2 that were present in the Port Up or Port Down message. The message MUST also contain a Status-Info TLV that in turn contains other information appropriate to the message header Result Code value as described in Section 3.6.1.4.6.5. TLVs for DSL Line Attributes
As specified above, the DSL-Line-Attributes TLV is inserted into the Port Up or Port Down message at the top level. The remaining TLVs defined below are encapsulated within the DSL-Line-Attributes TLV.6.5.1. DSL-Line-Attributes TLV
Type: 0x0004 Description: This TLV encapsulates attribute values for a DSL access line serving a subscriber. Length: Variable (up to 1023 bytes) Value: One or more encapsulated TLVs corresponding to DSL access line attributes. The DSL-Line-Attributes TLV MUST contain at least one TLV when it is present in a Port Up or Port Down message. The actual contents are determined by the AN control application.
6.5.2. DSL-Type TLV
Type: 0x0091 Description: Indicates the type of transmission system in use. Length: 4 bytes Value: 32-bit unsigned integer ADSL1 = 1 ADSL2 = 2 ADSL2+ = 3 VDSL1 = 4 VDSL2 = 5 SDSL = 6 OTHER = 06.5.3. Actual-Net-Data-Rate-Upstream TLV
Type: 0x0081 Description: Actual upstream net data rate on a DSL access line. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.4. Actual-Net-Data-Rate-Downstream TLV
Type: 0x0082 Description: Actual downstream net data rate on a DSL access line. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.5. Minimum-Net-Data-Rate-Upstream TLV
Type: 0x0083 Description: Minimum upstream net data rate desired by the operator. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.6. Minimum-Net-Data-Rate-Downstream TLV
Type: 0x0084 Description: Minimum downstream net data rate desired by the operator. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.7. Attainable-Net-Data-Rate-Upstream TLV
Type: 0x0085 Description: Maximum net upstream rate that can be attained on the DSL access line. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.8. Attainable-Net-Data-Rate-Downstream TLV
Type: 0x0086 Description: Maximum net downstream rate that can be attained on the DSL access line. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.9. Maximum-Net-Data-Rate-Upstream TLV
Type: 0x0087 Description: Maximum net upstream data rate desired by the operator. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.10. Maximum-Net-Data-Rate-Downstream TLV
Type: 0x0088 Description: Maximum net downstream data rate desired by the operator. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.11. Minimum-Net-Low-Power-Data-Rate-Upstream TLV
Type: 0x0089 Description: Minimum net upstream data rate desired by the operator in low power state. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer6.5.12. Minimum-Net-Low-Power-Data-Rate-Downstream TLV
Type: 0x008A Description: Minimum net downstream data rate desired by the operator in low power state. Length: 4 bytes Value: Rate in kbits/s as a 32-bit unsigned integer
6.5.13. Maximum-Interleaving-Delay-Upstream TLV
Type: 0x008B Description: Maximum one-way interleaving delay. Length: 4 bytes Value: Time in ms as a 32-bit unsigned integer6.5.14. Actual-Interleaving-Delay-Upstream TLV
Type: 0x008C Description: Value corresponding to the interleaver setting. Length: 4 bytes Value: Time in ms as a 32-bit unsigned integer6.5.15. Maximum-Interleaving-Delay-Downstream TLV
Type: 0x008D Description: Maximum one-way interleaving delay. Length: 4 bytes Value: Time in ms as a 32-bit unsigned integer6.5.16. Actual-Interleaving-Delay-Downstream
Type: 0x008E Description: Value corresponding to the interleaver setting. Length: 4 bytes Value: Time in ms as a 32-bit unsigned integer
6.5.17. DSL-Line-State TLV
Type: 0x008F Description: The state of the DSL access line. Length: 4 bytes Value: 32-bit unsigned integer SHOWTIME = 1 IDLE = 2 SILENT = 36.5.18. Access-Loop-Encapsulation TLV
Type: 0x0090 Description: The data link protocol and, optionally, the encapsulation overhead on the access loop. When this TLV is present, at least the data link protocol MUST be indicated. The encapsulation overhead MAY be indicated. The Access Node MAY choose to not convey the encapsulation on the access loop by specifying values of 0 (NA) for the two encapsulation fields. Length: 3 bytes Value: The 3 bytes (most to least significant) and valid set of values for each byte are defined as follows: Byte 1: Data Link ATM AAL5 = 0 ETHERNET = 1 Byte 2: Encapsulation 1 NA = 0 Untagged Ethernet = 1 Single-tagged Ethernet = 2 Double-tagged Ethernet = 3
Byte 3: Encapsulation 2
NA = 0
PPPoA LLC = 1
PPPoA Null = 2
IPoA LLC = 3
IPoA Null = 4
Ethernet over AAL5 LLC with FCS = 5
Ethernet over AAL5 LLC without FCS = 6
Ethernet over AAL5 NULL with FCS = 7
Ethernet over AAL5 NULL without FCS = 8
The Access-Loop-Encapsulation TLV is illustrated in Figure 16.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 0x0090 | Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data link | Encaps 1 | Encaps 2 | Padding (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: The Access-Loop-Encapsulation TLV
7. ANCP-Based DSL Line Configuration
The use case for ANCP-based DSL Line Configuration is described in
Section 3.2 of [RFC5851].
7.1. Control Context (Informative)
Triggered by topology information reporting a new DSL access line or
triggered by a subsequent user session establishment (via PPP or
DHCP), RADIUS/AAA sends service parameters to the NAS control
application for configuration on the access line. The NAS control
application passes the request on to the NAS-side agent, which sends
the information to the AN by means of a Port Management (line
configuration) message. The AN-side agent passes this information up
to the AN control application, which applies it to the line.
Figure 17 summarizes the interaction.
Home Access NAS RADIUS/AAA Gateway Node Policy Server -----------> ---------------> DSL Port Up message) Signal (line parameters) --------------------------------> --------------> PPP/DHCP Session Authentication & authorization <---------------- Port Management message (line configuration) Figure 17: Message Flow - ANCP Mapping for Initial Line Configuration The NAS could update the line configuration as a result of a subscriber service change (e.g., triggered by the policy server). Figure 18 summarizes the interaction. User Home Access NAS Gateway Node --------------------------> PPP/DHCP Session ----------------------------------------------------> Web portal, Service on demand OSS, etc. | <----------- RADIUS/AAA Change of Policy Server authorization <------------ Port Management message (new profile) OSS: Operations Support System Figure 18: Message Flow - ANCP Mapping for Updated Line Configuration
7.2. Protocol Requirements
The DSL access line configuration capability is assigned capability type 0x0002. No capability data is associated with this capability.7.2.1. Protocol Requirements on the NAS Side
The NAS-side ANCP agent MUST be able to create DSL-specific Port Management (line configuration) messages according to the format specified in Section 7.3. The NAS-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. The NAS-side ANCP agent MUST follow the NAS-side procedures associated with DSL-specific Port Management (line configuration) messages as they are specified in Section 7.4.7.2.2. Protocol Requirements on the AN Side
The AN-side ANCP agent MUST conform to the normative requirements of Section 5.1.2. The AN-side ANCP agent MUST be able to receive and validate DSL- specific Port Management (line configuration) messages according to the format specified in Section 7.3. The AN-side ANCP agent MUST follow the AN-side procedures associated with DSL-specific Port Management (line configuration) messages as specified in Section 7.4.
7.3. ANCP Port Management (Line Configuration) Message Format
The ANCP Port Management message for DSL access line configuration has the format shown in Figure 19. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/IP Encapsulating Header (Section 3.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ANCP General Message Header | + (Section 3.6.1) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unused (12 bytes) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused (2 bytes) | Function=8 | X-Function=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x|x|x|x| Message Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of TLVs | Extension Block length (bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Access line identifying TLV(s) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Line configuration TLV(s) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NOTE: TLVs MAY be in a different order from what is shown in this figure. Figure 19: Port Management Message for DSL Line Configuration See Section 3.6 for a description of the ANCP general message header. The Message Type field MUST be set to 32. The 12-bit Result Code field MUST be set to 0x0. The 4-bit Result field MUST be set to either 0x1 (Nack) or 0x2 (AckAll), as determined by policy on the NAS. The 24-bit Transaction Identifier field MUST be set to a positive value. Other fields in the general header MUST be set as described in Section 3.6.
The handling of the various unused/reserved fields is described in Section 3.4. The remaining message fields are described as follows: Function (8 bits): Action to be performed. For line configuration, Function MUST be set to 8 (Configure Connection Service Data). This action type requests the Access Node (i.e., DSLAM) to apply service configuration data contained in the line configuration TLVs to the DSL access line designated by the access line identifying TLVs. X-Function (8 bits): Qualifies the action set by Function. For DSL access line configuration, this field MUST be set to 0. Extension Flags (8 bits): The flag bits denoted by 'x' before the Message Type field are reserved for future use. Message Type (8 bits): Message Type has the same value as in the general header (i.e., 32). Reserved (16 bits): Reserved for future use. # of TLVs (16 bits): The number of TLVs that follow, not counting TLVs encapsulated within other TLVs. Extension Block Length (16 bits): The total length of the TLVs carried in the extension block in bytes, including any padding within individual TLVs. TLVs: Two or more TLVs to identify a DSL access line and configure its service data. Other ANCP capabilities, either specific to DSL or technology- independent, MAY reuse the Port Management message for service configuration. If the settings of the fixed fields are compatible with the settings just described, the same Port Management message that is used for DSL access line configuration MAY be used to carry TLVs relating to the other capabilities that apply to the same DSL access line. Use of the Port Management message for configuration MAY also be generalized to other access technologies, if the respective capabilities specify use of access line identifiers appropriate to those technologies in place of the identifiers defined in Section 5.1.2.
7.4. Procedures
Service configuration MAY be performed on an access line regardless of its current state.7.4.1. Procedures on the NAS Side
When requested by the NAS control application and presented with the necessary information to do so, the NAS-side agent MUST create and send a Port Management message with the fixed fields set as described in the previous section. The message MUST contain one or more TLVs to identify an access line according the requirements of Section 5.1.2. The NAS MUST include one or more TLVs to configure line service parameters for that line. Section 7.5 currently identifies only one such TLV, Service-Profile-Name, but other TLVs MAY be added by extensions to ANCP.7.4.2. Procedures on the AN Side
The AN-side ANCP agent MUST be prepared to receive Port Management (line configuration) messages for a given DSL access line or logical port at any time after negotiation of an adjacency has been completed. The AN-side ANCP agent SHOULD validate each message against the specifications given in Section 7.3 and the TLV specifications given in Sections 5.1.2 and 7.5. If it finds an error it MUST return a Port Management response message that copies the Port Management request as it was received, but has the Result header field set to 0x04 (Failure) and the Result Code field set to the appropriate value. The AN-side agent MAY add a Status-Info TLV (Section 4.5) to provide further information on the error, particularly if this is recommended in Section 3.6.1.4 for the given Result Code value. If it does so, the various length fields and the # of TLVs field within the message MUST be adjusted accordingly.7.5. TLVs for DSL Line Configuration
Currently, only the following TLV is specified for DSL access line configuration. More TLVs may be defined in a future version of this specification or in ANCP extensions for individual service attributes of a DSL access line (e.g., rates, interleaving delay, multicast channel entitlement access-list).
7.5.1. Service-Profile-Name TLV
Type: 0x0005 Description: Reference to a pre-configured profile on the DSLAM that contains service-specific data for the subscriber. Length: Up to 64 bytes Value: ASCII string containing the profile name (which the NAS learns from a policy server after a subscriber is authorized).
(page 65 continued on part 4)
