draft-ietf-ancp-protocol-14.txt   draft-ietf-ancp-protocol-15.txt 
Network Working Group S. Wadhwa Network Working Group S. Wadhwa
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track J. Moisand Intended status: Standards Track J. Moisand
Expires: July 15, 2011 Juniper Networks Expires: August 6, 2011 Juniper Networks
T. Haag T. Haag
Deutsche Telekom Deutsche Telekom
N. Voigt N. Voigt
Nokia Siemens Networks Nokia Siemens Networks
T. Taylor, Ed. T. Taylor, Ed.
Huawei Technologies Huawei Technologies
January 11, 2011 February 2, 2011
Protocol for Access Node Control Mechanism in Broadband Networks Protocol for Access Node Control Mechanism in Broadband Networks
draft-ietf-ancp-protocol-14 draft-ietf-ancp-protocol-15
Abstract Abstract
This document describes the Access Node Control Protocol (ANCP). This document describes the Access Node Control Protocol (ANCP).
ANCP operates between a Network Access Server (NAS) and an Access ANCP operates between a Network Access Server (NAS) and an Access
Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in
a multi-service reference architecture in order to perform QoS- a multi-service reference architecture in order to perform QoS-
related, service-related and subscriber-related operations. Use related, service-related and subscriber-related operations. Use
cases for ANCP are documented in RFC 5851. As well as describing the cases for ANCP are documented in RFC 5851. As well as describing the
base ANCP protocol, this document specifies capabilities for Digital base ANCP protocol, this document specifies capabilities for Digital
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 15, 2011. This Internet-Draft will expire on August 6, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 25, line 30 skipping to change at page 25, line 30
3.6.2. The ANCP Message Body 3.6.2. The ANCP Message Body
The detailed contents of the message payload portion of a given ANCP The detailed contents of the message payload portion of a given ANCP
message can vary with the capability in the context of which it is message can vary with the capability in the context of which it is
being used. However, the general format consists of zero or more being used. However, the general format consists of zero or more
fixed fields, followed by a variable amount of data in the form of fixed fields, followed by a variable amount of data in the form of
Type-Length-Value (TLV) data structures. Type-Length-Value (TLV) data structures.
The general format of a TLV is shown in Figure 7: The general format of a TLV is shown in Figure 7:
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 (IANA registered) | Length | | Type (IANA registered) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: General TLV Format Figure 7: General TLV Format
skipping to change at page 26, line 8 skipping to change at page 26, line 8
established for ANCP TLV Type codes. established for ANCP TLV Type codes.
Length: The number of bytes of data in the Value field of the TLV, Length: The number of bytes of data in the Value field of the TLV,
excluding any padding required to bring this TLV to a 4-byte word excluding any padding required to bring this TLV to a 4-byte word
boundary (see "Value" below). If a TLV contains other TLVs, any boundary (see "Value" below). If a TLV contains other TLVs, any
padding in the contained TLVs MUST be included in the value of padding in the contained TLVs MUST be included in the value of
Length. Depending on the specification of the TLV, the value of Length. Depending on the specification of the TLV, the value of
Length can be zero, a constant for all instances of the TLV, or a Length can be zero, a constant for all instances of the TLV, or a
varying quantity. varying quantity.
Value The actual data carried by the TLV, if any. The value field Value: The actual data carried by the TLV, if any. The value field
in each TLV MUST be padded with zeroes as required to align with a in each TLV MUST be padded with zeroes as required to align with a
4-byte word boundary. The Value field of a TLV MAY include fixed 4-byte word boundary. The Value field of a TLV MAY include fixed
fields and/or other TLVs. fields and/or other TLVs.
Unless otherwise specified, TLVs MAY be added to a message in any Unless otherwise specified, TLVs MAY be added to a message in any
order. If the recipient of a message does not understand a order. If the recipient of a message does not understand a
particular TLV, it MUST silently ignore it. particular TLV, it MUST silently ignore it.
A number of TLVs are specified in the remainder of this document. A number of TLVs are specified in the remainder of this document.
skipping to change at page 69, line 23 skipping to change at page 69, line 23
Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel Derek Harkness, Kim Hyldgaard, Sandy Ng, Robert Peschi, and Michel
Platnic. Platnic.
12. References 12. References
12.1. Normative References 12.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",
RFC 3046, January 2001.
[RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
"General Switch Management Protocol (GSMP) V3", RFC 3292, "General Switch Management Protocol (GSMP) V3", RFC 3292,
June 2002. June 2002.
[RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch [RFC3293] Worster, T., Doria, A., and J. Buerkle, "General Switch
Management Protocol (GSMP) Packet Encapsulations for Management Protocol (GSMP) Packet Encapsulations for
Asynchronous Transfer Mode (ATM), Ethernet and Asynchronous Transfer Mode (ATM), Ethernet and
Transmission Control Protocol (TCP)", RFC 3293, June 2002. Transmission Control Protocol (TCP)", RFC 3293, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
 End of changes. 7 change blocks. 
9 lines changed or deleted 6 lines changed or added

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