| TOC |
|
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 December 7, 2009.
Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
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.
The following notes (up until the start of "Requirements Language" will be deleted before Working Group Last Call
NOTE the family of Address Types is known to be incomplete. The authors request that members of the MPLS-TP community provide details of their required address formats in the form of text for the creation of an additional sections similar to Section 3.1 (IPv4 Address).
NOTE other TLV types will be added in further revisions of this document. The authors request that members if the MPLS-TP community requiring new TLVs to complete there MPLS-TP specifications provide details of their required TLV in the form of text for the creation of additional sections similar to Section 2.2 (Source Address ).
NOTE The intension is to keep this document as a living list of TLVs for some time. When the Working Groups consider that we have captured the majority of the TLVs we will close the document and submit for publication.
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].
1.
Introduction
2.
ACH TLV Object Definitions
2.1.
The Null TLV Object
2.2.
Source Address
2.3.
Destination Address
2.4.
Label Switched Path Identifier (LSPI)
2.5.
Pseudowire Identifier (PWI)
3.
ACH Addresses
3.1.
IPv4 Address
3.2.
IPv6 Address
4.
ACH Protocol ID TLV
5.
Security Considerations
6.
IANA Considerations
7.
References
7.1.
Normative References
7.2.
Informative References
§
Authors' Addresses
| TOC |
The MPLS generic associated channel header specification [7] (Bocci, M., Vigoureux, M., Bryant, S., Swallow, G., Ward, D., and R. Aggarwal, “MPLS Generic Associated Channel,” May 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 [8] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” August 2009.), [9] (Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” April 2010.). One use of these TLVs to identify the source and/or intended destination of the ACH payload for use in transport networks. However the use of this construct is not limited to providing addressing information nor is the applicability restricted to transport network applications.
Additionally TLVs from defined in this document may be used as sub-TLVs in the construction of compound TLV structures.
| 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 just 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 source address (SA) 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 being responded to.
The address is an ACH address as described in Section 3 (ACH Addresses).
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2: Source Address |
| TOC |
This TLV specifies the destination address (DA) of an ACH packet.
Where the packet is associated with a maintenance request/response operation it refers to the target of the operation, i.e. It is the address of the Maintenance End Point or Maintenance Intermediate Point that has been requested to execute the operation being either requested, or being responded to.
The address is an ACH address as described in Section 3 (ACH Addresses).
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3: Destination Address |
| TOC |
This TLV is used to identify a Label Switched Path (LSP).
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TBD | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4: Label Switched Path Identifier |
This will draw on the contents of [2] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). Further material will be added in a future version of this document.
| TOC |
This TLV is used to identify a pseudowire.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TBD | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 5: Pseudowire Identifier |
This will draw on the contents of [2] (Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” February 2006.). Further material will be added in a future version of this document.
| TOC |
This section is incomplete. Definitions of other address types will be provided in a future version of this document. The authors would like to take input from other members of the MPLS-TP design community as to the required additional addressing types and the correct way to represent them in this framework.
Addresses are expressed in the following TLV format. This representation allows ACH TLVs to be specified in a format that is independent of the address that are to be used in the TV instance. Although many address types are of fixed length, and some which are not incorporate a length indicator, this may not always be the case and hence a length field is incorporated in the address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AdrType | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOC |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AdrType = 1 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This address TLV contains an IPv4 address as defined in [3] (Postel, J., “Internet Protocol,” September 1981.).
| TOC |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AdrType = 2 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IPv6 Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This address TLV contains an IPv6 address as defined in [4] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.)
| TOC |
The ACH Protocol ID TLV is used to identify the payload protocol type for a message carried on the GACH. The TLV is OPTIONAL in the GACH header, but MUST be present for the Data Communications Network (DCN) [10] (Beller, D. and A. Farrel, “An Inband Data Communication Network For the MPLS Transport Profile,” September 2009.) .
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 = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of the Protocol Identifier field is taken from PPP DLL Protocol Number Registry [5] (Simpson, W., “The Point-to-Point Protocol (PPP),” July 1994.), [6] (Schryver, V., “IANA Considerations for the Point-to-Point Protocol (PPP),” June 2004.).
| 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 two new registries in the pseudowire name spaces: the ACH TLV Registry and the ACH Address Type 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
SA 1 var Source Addr This Draft
DA 2 var Dest Addr This Draft
LSPI 3 var LSP Identifier This Draft
PWI 4 var PW Identifier This Draft
PID 5 2 ACH Protocol ID This Draft
The ACH Address Type 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 Reserved
IPv4 1 4 IPv4 Address This Draft
IPv6 2 16 IPv6 Address 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] | Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures,” RFC 4379, February 2006 (TXT). |
| [3] | Postel, J., “Internet Protocol,” STD 5, RFC 791, September 1981 (TXT). |
| [4] | Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML). |
| [5] | Simpson, W., “The Point-to-Point Protocol (PPP),” STD 51, RFC 1661, July 1994 (TXT). |
| [6] | Schryver, V., “IANA Considerations for the Point-to-Point Protocol (PPP),” BCP 88, RFC 3818, June 2004 (TXT). |
| TOC |
| [7] | Bocci, M., Vigoureux, M., Bryant, S., Swallow, G., Ward, D., and R. Aggarwal, “MPLS Generic Associated Channel,” draft-ietf-mpls-tp-gach-gal-06 (work in progress), May 2009 (TXT). |
| [8] | Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “MPLS-TP Requirements,” draft-ietf-mpls-tp-requirements-10 (work in progress), August 2009 (TXT). |
| [9] | 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). |
| [10] | Beller, D. and A. Farrel, “An Inband Data Communication Network For the MPLS Transport Profile,” draft-ietf-mpls-tp-gach-dcn-06 (work in progress), September 2009 (TXT). |
| TOC |
| Sami Boutros | |
| Cisco Systems | |
| Phone: | |
| Fax: | |
| Email: | sboutros@cisco.com |
| URI: | |
| Stewart Bryant (editor) | |
| Cisco Systems | |
| Phone: | |
| Fax: | |
| Email: | stbryant@cisco.com |
| URI: | |
| Siva Sivabalan | |
| Cisco Systems | |
| Phone: | |
| Fax: | |
| Email: | msiva@cisco.com |
| URI: | |
| George Swallow | |
| Cisco Systems | |
| Phone: | |
| Fax: | |
| Email: | swallow@cisco.com |
| URI: | |
| David Ward | |
| Cisco Systems | |
| Phone: | |
| Fax: | |
| Email: | dward@cisco.com |
| URI: |