| TOC |
|
In some application of the associated channel header (ACH), it is necessary to have the ability to include a set of TLVs to provide additional context information for the ACH payload. This document defines a number of TLV types.
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1].
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
1.
Introduction
2.
ACH TLV Object Definitions
2.1.
The Null TLV Object
2.2.
IPv4 Source Address
2.3.
IPv6 Source Address
2.4.
ITU-T Carrier Code
2.5.
Global Identifier
2.6.
Network Interface Identifier
2.7.
Authentication
3.
Security Considerations
4.
IANA Considerations
5.
References
5.1.
Normative References
5.2.
Informative References
§
Authors' Addresses
| TOC |
The MPLS generic associated channel header specification [6] (Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” June 2009.) (GACH) describes a TLV structure that is used to provide additional context information for the ACH payload. This document defines a number of TLVs that are required by the MPLS-TP design [7] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.), [8] (Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” April 2010.).
| TOC |
This section provides the definition for a number of ACH TLV objects. In each case the length in the TLV header is the length of only the value component.
| TOC |
The Null TLV provides an OPTIONAL mechanism of restoring 32bit alignment of the following element in the packet and also provides an OPTIONAL mechanism to reserve space in the packet to be used by TLV objects that will be written by LSR that perform some operation on the packet at a later time. For security reasons the value must be zero.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value = 0 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 1: Null TLV Object |
| TOC |
This TLV specifies the IPv4 [2] (Postel, J., “Internet Protocol,” September 1981.) source address (SAv4) of an ACH packet.
Where the packet is associated with a maintenance request/response operation it refers to the requester of the operation, i.e. It is the address of the Maintenance End Point that initiated the operation being either requested, or is being responded to.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 1 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2: IPv4 Source Address |
| TOC |
This TLV specifies the IPv6 [3] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) source address (SAv6) of an ACH packet.
Where the packet is associated with a maintenance request/response operation it refers to the requester of the operation, i.e. It is the address of the Maintenance End Point that initiated the operation being either requested, or is being responded to.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3: IPv4 Source Address |
| TOC |
This TLV is used to carry an ITU-T Carrier Code Identifier (ICC) as defined in M.1400 [4] (, “ITU-T Recommendation M.1400, "Designations for interconnections among operators' networks",” 2006.).
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 3 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICC | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4: ITU-T Carrier Code |
The ICC is encoded in ASCII in a fixed format 6 byte field, with unused trailing bytes set to NULL (0).
| TOC |
This TLV is used to carry a Global Identifier (Global_ID) [5] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” March 2010.) .
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 4 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 5: Global_ID TLV |
| TOC |
This TLV is used to carry Network Interface ID (IF_ID) [5] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” March 2010.) . As defined in [5] (Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” March 2010.), an IF_ID consists of a node identifier (Node_ID) and a Logical Interface Handle (LIH), both or which are 32 bit identifiers.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LIH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 6: IF_ID TLV |
| TOC |
The structure of the ACH authentication (auth) TLV is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AchTlvType = 6 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The authentication proceedures and data format used is the same as that defined in Sections 4.1, 4.2, 4.3 and 4.4 of [9] (Katz, D. and D. Ward, “Bidirectional Forwarding Detection,” January 2010.) .
Each document which defines a channel type needs to define whether an authentication TLV is required, permitted, or disallowed, and the actions to be taken in normal and error situations.
An application not supporting data origin authentication MAY use this mechanism instead of defining its own proprietery mechanism.
| TOC |
This specification defines a mechanism to identify a set of protocol parameters. The necessary security considerations will be described in the definition of the protocols that uses these parameters.
| TOC |
IANA is requested to create a new registry in the pseudowire name spaces: the ACH TLV Registry.
The ACH TLV Registry should be initialized with the following entries. The allocation policy for this registry is IETF consensus.
Name Type Length Description Reference
(octets)
Null 0 3 Null TLV This Draft
SAv4 1 4 IPv4 Source Address This Draft
SAv6 2 16 IPv6 Source Address This Draft
ICC 3 6 ITU-T Carrier Code This Draft
Global_ID 4 4 Global Identifier This Draft
IF_ID 5 8 Network Interface ID This Draft
Auth 6 var Authentication This Draft
| TOC |
| TOC |
| [1] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [2] | Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT). |
| [3] | Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML). |
| [4] | “ITU-T Recommendation M.1400, "Designations for interconnections among operators' networks",” 2006. |
| [5] | Bocci, M. and G. Swallow, “MPLS-TP Identifiers,” draft-ietf-mpls-tp-identifiers-01 (work in progress), March 2010 (TXT). |
| TOC |
| [6] | Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” RFC 5586, June 2009 (TXT). |
| [7] | Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” RFC 5654, September 2009 (TXT). |
| [8] | Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” draft-ietf-mpls-tp-framework-11 (work in progress), April 2010 (TXT). |
| [9] | Katz, D. and D. Ward, “Bidirectional Forwarding Detection,” draft-ietf-bfd-base-11 (work in progress), January 2010 (TXT). |
| TOC |
| Sami Boutros | |
| Cisco Systems | |
| Email: | sboutros@cisco.com |
| Stewart Bryant (editor) | |
| Cisco Systems | |
| Email: | stbryant@cisco.com |
| Siva Sivabalan | |
| Cisco Systems | |
| Email: | msiva@cisco.com |
| George Swallow | |
| Cisco Systems | |
| Email: | swallow@cisco.com |
| David Ward | |
| Juniper Networks | |
| Email: | dward@Juniper.net |
| Vishwas Manral | |
| IP Infusion Inc. | |
| Bamankhola, | |
| Bansgali,, Almora, Uttaranchal 263601 | |
| India | |
| Email: | vishwas.ietf@gmail.com |