TOC 
MPLSS. Boutros
Internet-DraftS. Bryant, Ed.
Intended status: Standards TrackS. Sivabalan
Expires: November 30, 2009G . Swallow
 D. Ward
 Cisco Systems
 May 29, 2009


Definition of ACH TLV Structure
draft-bryant-mpls-tp-ach-tlv-02

Status of this Memo

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 November 30, 2009.

Copyright Notice

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.

Abstract

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.

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 ).

Requirements Language

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].



Table of Contents

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 

1.  Introduction

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 

2.  ACH TLV Object Definitions

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 

2.1.  The Null TLV Object

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 

2.2.  Source Address

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 

2.3.  Destination Address

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 

2.4.  Label Switched Path Identifier (LSPI)

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 

2.5.  Pseudowire Identifier (PWI)

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 

3.  ACH Addresses

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          AddType              |       Length                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            Address                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

3.1.  IPv4 Address

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          AddType = 1          |       Length = 4              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This address TLV contains an IPv4 address as defined in [3] (Postel, J., “Internet Protocol,” September 1981.).



 TOC 

3.2.  IPv6 Address

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          AddType = 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 

4.  ACH Protocol ID TLV

The ACH Protocol ID TLV is used to identify the payload protocol type for a message carried on the G-ACh. The TLV is OPTIONAL in the G-ACh 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 

5.  Security Considerations

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 

6.  IANA Considerations

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 

7.  References



 TOC 

7.1. Normative References

[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.2. Informative References

[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 

Authors' Addresses

  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: