TOC 
MPLS Working GroupG. Liu
Internet-DraftJ. Yang
Intended status: InformationalL. Jiang
Expires: December 4, 2009ZTE Corporation
 June 02, 2009


Multiprotocol Label Switching Transport Profile Bidirectional Notify Message Packet
draft-liu-mpls-tp-bnm-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft.

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 4, 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

This document specifies an extension to MPLS BDI packet to form a new type of OAM packet BNM(Bidirectional Notify Message) , this BNM packet will not only have the function of informing another peer MEP about existing fault of this path like MPLS BDI packet, but also it may use for performance measure and testing communication between two equipments. in addtion, when Client network has a fault or defect. it notify another peer client network about remote peer fault. And these performance measure and fault notification information will be encapsulated in BNM packet by the way of TLV packet. So it may decrease the number of OAM type and keep compatibility with MPLS network. on the other hand, this encapsulating these information by the way of TLV packet will be easy to extend OAM function to operate an MPLS Transport profile(MPLS-TP) label switched path (LSP).



Table of Contents

1.  Introduction
2.  Conventions used in this document
3.  MPLS-TP BNM Message
    3.1.  LM TLV
    3.2.  DM TLV
    3.3.  Experimental TLV
    3.4.  Vendor Specific TLV
    3.5.  Client Signal Fail(CSF) TLV
    3.6.  Fault Message Notify TLV
    3.7.  other
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informative References
    7.3.  URL References
§  Authors' Addresses




 TOC 

1.  Introduction

this document mainly introduce a kind of new OAM packet(BNM) that can extend BDI packet and use encapsulation in the way of G-ACH. It used for a MEP to inform another MEP about fault message of the path or client network or measure the performance of a path or test communcation between two equipments. ,i.e ,LMM,DMM,VSR,EXR etc.thest kinds of fault notification or performance measure information, which may be encapsulated into BNM packet by the way of TLV will be sent to another MEP along MPLS-TP LSP. so it may ensure that it is easy to extend MPLS OAM function under the condition of not adding the number of MPLS OAM kinds



 TOC 

2.  Conventions used in this document

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 RFC-2119.

The following terminologies were defined in [Y.17TOM or Y.1711].

OAM: Operations, Administration, Maintenance

LSP: MPLS-TP Label Switched Path.

BDI:Backward Defect Indicator

CSF:Client Signal Fail

DMR:Delay Measurement Response

DM:Delay Measurement

DMM:Delay Measurement Message

EXM:Exercise Message

EXR:Exercise Response

LM:Loss Measurement

LMM:Loss Measurement Message

LMR:Loss Measurement Response

MPLS:Multi-Protocol Label Switching

MPLS-TP:Multi-Protocol Label Switching Transport Profile

SSM:Synchronisation Status Message

TLV:Type Length Value

VSM:Vendor Specific Message(special message packet)

VSR:Vendor Specific Response

TTSI:Trail Termination Source Identifier_source LER ID+LSP ID

BNM:Bidirectional Notify Message

MEP:MEG End Point



 TOC 

3.  MPLS-TP BNM Message

For mpls-tp BNM packet, it must be encapsulated by G-ACH to keep the same as all other MPLS-TP OAM packet. The G-ACH with MPLS-TP BNM code point indicates that the message is an MPLS BDI message. In addition, a 32-bit field is added to carry the LSP ID and the message length as shown below Figure 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|version|0 0 0 0 0 0 0 0 |       Channel Type(BNM)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         LSP ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Message Length         |     operator code


 Figure 1 



First Nibble: set 0001b;

Version: the second nibble, indicates the version of the MPLS-TP OAM Message Header , here set 0000;

Resv field:eight bits, all set 0;

channel type:16bit, the field value is 0x03 that is the same as mpls BDI code point;

LSP ID:the 32-bits field is set by the sender. The receiver MUST include the LSP ID in the response. This way, the sender can correlate a reply with the corresponding request.avoid misconnection or misrelative.

Message Length:the value of this field is the length of all TLV packets in the BNM packets. when the field value is 0, it indicates that there is no TLV packets in this BNM packet.

operator code: set 0,indicate request packet; set 1,indicate response packet; set 2,indicate echo information;



 TOC 

3.1.  LM TLV

LM TLV is used to measure packet loss performance of this path or LSP connection. firstly a MEP point will initiate a LM request message to another MEP points ,the LM request message will be encapsulated into BNM packet by the way of LM TLV. when another peer MEP receives this LM request message ,it will send LM response message to the MEP. The LM response message will also be the same way of encapsulation as the LM request message.then the MEP receives the LM response message ,it will process and analyse the LM response message and computer the packet loss performance of the path .so it will select a better performance path. the LM TLV packet show the following figure 2:




 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 |type = TBD|  length | sequence number| received number |   other |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


 Figure 2 



type: this field indicates LM TLV code point;

length:the length of the LM TLV;

sequence number: the sequence number of traffic packet that be sent by source point.so it can computer the number of total traffic packet that have already been sent during the period of time.

received number: the number of traffic packet that have already been received during the period of time.

other: (optional) it may carry other data information.



 TOC 

3.2.  DM TLV

DM TLV is used to measure one-way or two-way delay of a path .in order to measure delay, firstly a MEP point will send DM TLV request BNM packet to another MEP point of the path. and fill the timestamp into the timestamp field of DM TLV. when peer MEP point received the DM request TLV, for one-way delay measure,it will computer this one-way delay by timestamp of sending in DM request TLV and timestamp of receiving. for two-way delay measure, when peer MEP point received DM request TLV , it will fill timestamp of receiving into timestamp field forming a DM response TLV .Then the DM response TLV will be encapsulted into BNM to be sent to peer MEP point. so initiated MEP point can computer the two-way delay. And DM TLV shows the following figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  type = TBD   |  length   |              timestamp              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 Figure 3 



type: the field indicates DM TLV;

length:the length of the DM TLV;

timestamp: for DM request TLV,it indicates timestamp of sending DM request TLV. for DM response TLV, it indicates timestamp of receiving DM request TLV.



 TOC 

3.3.  Experimental TLV

Experimental TLV is used for experimental activities in cases where an OAM PDU type is not defined in MPLS-TP aspect. and it can be used within an administrative domain on a temporary basis. Firstly a MEP sends a experimental request TLV packet to another MEP for experimental activities. When another MEP receives the experimental request TLV and processes the packet. and then the result of experimental activity will be encapsulated into Experimental response TLV packet like EXR packet in BNM packet, then the sink MEP sends this BNM including Experimental response TLV to source MEP, so the source MEP understands or knows the result of experimental activity. The Experimental response TLV packet show below figure 4:




    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 = TBD   |  length = 0   |value of experimental activity |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 Figure 4 



type: the field indicates Experimental TLV;

length:the length of this Experimental TLV;

value: the data about Experimental activities;



 TOC 

3.4.  Vendor Specific TLV

Vendor Specific TLV may be used to check or test Interoperability by a vendor across its equipment. Firstly Vendor Specific Equipment MEP may send vendor specific request TLV packet to another Vendor Specific Equipment MEP. When another MEP received the Vendor Specific Request TLV packet and processed it .and then sink MEP can send a BNM packet including Vendor Specific response TLV to source MEP. And these Vendor Specific Equipment can communicate with each other . the Vendor Specific TLV packet show below figure 5:




    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 = TBD   |  length = 0 | value of interoperability state |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 Figure 5 



type: the field indicates Experimental TLV;

length:the length of this Experimental TLV;

value: the data of interoperability state;



 TOC 

3.5.  Client Signal Fail(CSF) TLV

Client Signal Fail(CSF) TLV is used to to propagate a Client Signal Fail (CSF) indication to the far-end MPLS-TP client-specific sink-adaptation process on detection of a failure of the ingress client signal in case the client-layer itself does not support an alarm suppression mechanism. This BNM packet in which may have encapsulated CSF TLV can be issued by a MEP upon receiving signal fail information from its client-layer. When far-end MEP received this BNM packet including CSF TLV and processed it , the MEP detects a client-layer signal fail condition and forward this as a signal fail indication to its client-layer, this CSF TLV packet show below figure 6:




    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 = TBD   |  length = 0   |     value of CSF state        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 Figure 6 



type: the field indicates Client Signal Fail(CSF) TLV;

length:the length of this Client Signal Fail(CSF) TLV;

value: the data of CSF state;



 TOC 

3.6.  Fault Message Notify TLV

Fault Message Notify TLV that is like BDI packet is used to inform the far-peer MEP point that there is a defect in its upstream or downstream segment of the LSP When there is a fault happened in the LSP, Then fault type and location information will be filled in Fault Message Notify TLV packet and further can be encapsulated into BNM packet that will be sent to the far-end MEP point. so the MEP point will trigger 1:1 or 1:n protection switching; the Fault Message Notify TLV structure show below figure 7:




    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 = TBD   |  length = 0   |     fault type and location   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


 Figure 7 



type: the field indicates Fault Message Notify TLV;

length:the length of this Fault Message Notify TLV;

value: indicates fault type and location;



 TOC 

3.7.  other

The BNM packet can not only realize these functions, but also it may realize other functions by extending TLV packet, i.e Synchronisation Status Message(SSM) may be encapsulated into a TLV packet that can be further encapsulated into the BNM packet. so by extending TLV packet, it is easy that BNM packet may support more other functions.



 TOC 

4.  Security Considerations

The security considerations for the authentication TLV need further study.



 TOC 

5.  IANA Considerations

TBD.



 TOC 

6.  Acknowledgments

TBD.



 TOC 

7.  References



 TOC 

7.1. Normative References

[IETF RFC4377] IETF, “IETF RFC4377(Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks),” February 2006.
[ITUT-Y.1711] ITU-T, “ITU-T Recommendation Y.1711(Operation Maintenance mechanism for MPLS networks),” February 2004.


 TOC 

7.2. Informative References

[ITUT-Y.17TOM Draft] ITU-T, “Draft ITU-T Recommendation Y.17TOM (Operation Maintenance mechanism for T-MPLS layer networks),” April 2007.
[MPLS-TP JWT REPORT] S.Bryant, L.Andersson, “JWT Report on MPLS Architectural Considerations for a Transport Profile,” July 2008.
[MPLS-TP Requirements] B.Niven-Jenkins, D.Brungard, M.Betts,N. Sprecher ,S.Ueno, “MPLS transport profile Requirements,” January 2009.
[Requirements for OAM in MPLS Transport Networks] M.Vigoureux, D.Ward, M.Betts , “Requirements for OAM in MPLS Transport Networks,” November 2008.


 TOC 

7.3. URL References

[MPLS-TP-22] IETF - ITU-T Joint Working Team, “,” 2008.


 TOC 

Authors' Addresses

  Guoman Liu
  ZTE Corporation
  No.68, Zijinghua Road, Yuhuatai District
  Nanjing 210012
  P.R.China
Phone:  +86 025 52871606
Email:  liu.guoman@zte.com.cn
  
  Jian Yang
  ZTE Corporation
  5F,RD Building 3,ZTE Industrial Park,XiLi LiuXian Road
  Nanshan District,Shenzhen 518055
  P.R.China
Phone:  +86 755 26773731
Email:  yang_jian@zte.com.cn
  
  Lili Jiang
  ZTE Corporation
  No.68, Zijinghua Road, Yuhuatai District
  Nanjing 210012
  P.R.China
Phone:  +86 025 52871745
Email:  jiang.lili@zte.com.cn