MPLS Y. Ji
Internet Draft Y. Lu
Intended status: Standards Track Z. Du
Expires: March 2010 BUPT University
September 4, 2009
The Mechanism of MPLS-TP OAM Communication
Based on MPLS-TP Sign Label
draft-ji-mpls-tp-sign-label-00.txt
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 March 4, 2010.
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
Ji, et al. Expires March 4, 2010 [Page 1]
Internet-Draft MTSL September 2009
This document extends the applicability of the Generic Associated
channel Label (GAL), enabling the realization of the communication
between a Maintenance End Point (MEP) and a Maintenance Intermediate
Point (MIP) in the MPLS-TP OAM architecture. This mechanism can only
be used in the point-to-point co-routed bidirectional path of MPLS-
TP networks. By introducing the MPLS-TP Sign Label, it enables the
peer MEP to obtain the path information along the MPLS Label
Switched Paths (LSPs) or MPLS pseudowires (PWs). After that, it
could number the MIPs along the path, and each MIP could record the
pairing relationship of the forward and the backward directions of
that transport path.
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 RFC 2119 [1].
Table of Contents
1. Introduction................................................2
2. MPLS-TP Sign Label..........................................3
3. Path Numbering Mechanism.....................................5
4. TTL LFIB....................................................7
5. Related ACH TLV Format.......................................8
5.1. The confirmation request message........................9
5.2. The confirmation message...............................10
5.3. The path numbering reply message.......................10
6. Applicability..............................................11
7. Security Considerations.....................................11
8. IANA Considerations........................................11
9. References.................................................12
9.1. Normative References...................................12
9.2. Informative References.................................12
10. Acknowledgments...........................................12
1. Introduction
MPLS-TP OAM operates in the context of Maintenance Entities (MEs).
For example, in the point-to-point co-routed bidirectional path of
MPLS-TP networks, an ME includes two Maintenance End Points (MEPs),
which reside at the boundaries of the ME, and MAY also include zero
or a set of Maintenance Intermediate Points (MIPs), which reside
within the ME, between the MEPs [8].
Ji, et al. Expires March 4, 2010 [Page 2]
Internet-Draft MTSL September 2009
MEPs are capable of initiating and terminating OAM messages.
Meanwhile, MIPs are unaware of any OAM flows running between MEPs or
between MEPs and other MIPs. MIPs can only receive and process OAM
packets addressed to the MIP itself.
When an MEP need to send an OAM message to an MIP, it sets the TTL
of the LSP, Tandem Connection Monitoring (TCM) or PW label so that
it will expire when the target MIP is reached. Then MIPs will find
that the packet has a GAL just below the current label, so it will
make a further scrutiny. After proper processing, a reply, if
required, is returned to the MEP that originated this message [9].
When the OAM packets are encapsulated in an IP header by default,
the process above is easy to realize. But MPLS-TP OAM can not rely
on this mechanism. In the environments where IP based routing and
forwarding are not supported, how to send this reply and make the
MEP know which MIP sends the message is uncertain.
This document proposed a method to specify how the reply is returned
and the related number mechanism by extending the former mechanism.
The basic idea is that in the point-to-point co-routed bidirectional
path of MPLS-TP networks, an MIP will record the pairing
relationship of the forward and the backward directions of that
transport path in a special Time To Live Label Forwarding
Information Base (TTL LFIB). Therefore, when it receives an OAM
packet and need to reply, the MIP will refer to the TTL LFIB to find
the outgoing label and the egress interface and accomplish the reply
process.
The outline of the mechanism is as follows. Firstly, the source MEP
sends a path numbering request packet along the path to the peer MEP,
which is also received by each MIP. When the MIPs receive this
packet, they will record the label information of the packet in TTL
LFIB and add the swap label information about this path to the
packet before forwarding. Secondly, the peer MEP receives this
packet, and it will send a confirmation request message to each MIP.
When the MIPs receive this message, they will accomplish the path
information in the TTL LFIB and return a confirmation message.
Finally, the peer MEP receives those confirmation messages. If they
are all success ones, it will send a success path numbering reply
message to the source MEP.
2. MPLS-TP Sign Label
In order to realize the path numbering and TTL LFIB establishing,
the peer MEP should obtain the path information firstly. This
document specifies that a label is used for that purpose and calls
Ji, et al. Expires March 4, 2010 [Page 3]
Internet-Draft MTSL September 2009
this special label the MPLS-TP Sign Label (MTSL). One of the
reserved label values defined in RFC 3032 [2] is assigned for this
purpose. The value of the label is to be allocated by IANA; this
document suggests the value 4.
The use of this label is analogous to the use of the Router Alert
Label. This label can be present anywhere in the label stack except
at the bottom. When the MTSL is the top label, it alerts the Label
Switching Router (LSR) that the packet needs a closer look.
Therefore, the packet is not forwarded in hardware, but is looked at
by a software process. When the packet is received, the MTSL is
removed. Then a lookup of the next label in the label stack is
performed in the Label Forwarding Information Base (LFIB) to decide
where the packet needs to be switched to. Next, a special label
action (push, swap, pop) is performed.
If the label action is push, which means the LSR is a subnetwork
ingress, the MTSL will be pushed back before normal push action and
will become invisible until the egress of the subnetwork. If the
label action is swap, which means the LSR is an MIP, the new label
will be pushed into the label stack instead of a normal swap action.
After that, the MTSL is pushed back on top of the label stack, and
the packet is forwarded. If the label action is pop, it means that
the packet gets to its destination, the peer MEP.
The format of the MTSL is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTSL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTSL: Label Value, 4 is supposed
TC: Traffic Class
S: Bottom of Stack, always zero here
TTL: Time to Live, 255 is initialed
Figure 1 The Format of the MTSL
Figure 2 shows the packet received by the peer MEP.
Ji, et al. Expires March 4, 2010 [Page 4]
Internet-Draft MTSL 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTSL | TC |0| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP or PW Label | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP or PW Label | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Other labels recorded along the path ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
......
Figure 2 The Path Numbering Packet Received by the Peer MEP
If the MTSL message exceeds the path MTU because of recording the
path's information continuously, the path numbering will fail. The
necessary logging and alarming will help the administrator to solve
the problem.
3. Path Numbering Mechanism
This mechanism can be used in the point-to-point co-routed
bidirectional path of MPLS-TP networks. This path's forward and
backward directions follow the same route (links and nodes) across
the network. Both directions are setup, monitored and protected as a
single entity [10]. The path may be an LSP or a PW with two Label
Edge Routers (LERs) and one or more LSRs. The two LERs act as the
source MEP and the peer MEP, and the LSRs act as the MIPs.
After the path is established, it is supposed that the two MEPs know
this path is a co-routed bidirectional path and the pairing
relationship of the two labels assigned to the forward and the
backward directions in this MEP. For the realization of this
mechanism, the MEPs SHOULD maintain an MIP number value in this
path's maintenance information, whose default value is -1.
This mechanism will start just after the establishment of the path.
The first step is to send the path numbering request message, whose
purpose is to number the MIPs and provide the path information hop-
by-hop to the peer MEP kindly like the function of the Record Route
Ji, et al. Expires March 4, 2010 [Page 5]
Internet-Draft MTSL September 2009
Object in RSVP-TE [3]. The source MEP sends a special packet with an
MTSL at the top of the label stack along the path to the peer MEP,
which is also received by each MIP.
When the MIPs receive this packet and find the MTSL, it is delivered
to a local software module for processing. The process procedures
are as follows.
Firstly, it records the TTL value of the MTSL, and then removes the
MTSL. The actual forwarding of the packet is determined by the label
beneath the MTSL in the stack.
Secondly, it looks up the label in the LFIB. It will find the
matching element because the path has been established and the
action should be swap. After that, it records the result, finishing
the forward numbering of the path in the TTL LFIB.
Thirdly, it changes the current label's S bits to 1, and pushes the
new label found in LFIB into the label stack, which has the same TC
bits, S bit and TTL bits as the current label.
Finally, it pushes back the MTSL and updates the TTL bits by
decreasing the TTL value recorded before by 1. And then, it forwards
the new packet which is a little bigger than before according to the
result of the former LFIB lookup.
When the peer MEP receives this packet and finds the MTSL, what it
does is a little different. Its process procedures are as follows.
Firstly, it records the TTL value of the MTSL, and then the MTSL is
removed. This step is the same as the former.
Secondly, it looks up the label in the LFIB. It will find the
matching element and the action should be pop. After that, it sends
a confirmation request message to each MIP along the path. This is
achieved by sending messages along the backward path to the source
MEP with the TTL set successively to 1, 2, and so on. The total
number of the messages will be the number of the MIPs, which is
computed as 255 minus the current TTL value recorded in the first
step of MTSL process procedure.
Thirdly, after the MIPs receive this message because of the TTL
expiring, they will accomplish the path information in the TTL LFIB
and return a confirmation message to the peer MEP.
Finally, the peer MEP receives those confirmation messages. If they
are all success ones, it will send a success path numbering reply
Ji, et al. Expires March 4, 2010 [Page 6]
Internet-Draft MTSL September 2009
message to the source MEP. And then, it will update the MIP number
value in this path's maintenance information.
4. TTL LFIB
TTL LFIB is analogous to LFIB and most of its data information is
copied from the LFIB of the LSR. Here the per platform label space
is used for example [4]. Its element includes followed contents:
Forward ingress label, forward number, forward egress interface,
forward egress label; backward ingress label, backward number,
backward egress interface, backward egress label.
When an MIP receives the MTSL packet, it will finish the forward
numbering of the path in the TTL LFIB. That procedure includes three
steps. Firstly, copy current incoming label beneath the MTSL to the
forward ingress label. Secondly, copy the outgoing interface and
label found in the LFIB to the backward egress interface and
backward egress label. Thirdly, compute the forward number.
Here it is supposed that when the source MEP sends the path
numbering request message, which is also called MTSL message in this
document, the TTL bits of the MTSL at the top of the label stack is
255 just like the default value set in RFC 3443 [5]. Then, when each
MIP receives the MTSL, the TTL will decrease by one by sequence. The
forward number will be computed as 256 minus the current TTL value
recorded in the first step of the MTSL process procedure.
When the MIPs receive the confirmation request message from the peer
MEP, it will finish the backward numbering of the path in the TTL
LFIB. That procedure also includes three steps. Firstly, copy
current incoming label to the backward ingress label. Secondly, copy
the outgoing interface and label found in LFIB according to the
incoming label to the forward egress interface and forward egress
label. Thirdly, set the backward number.
When the peer MEP sends the confirmation request message, it will
include a special ACH TLV which includes the label information
brought by the MTSL message to the peer MEP. The backward number
will be copied from the TLV information, which is further talked in
section 5.1.
After the path numbering process, each MIP will have a forward
number and a backward number. The forward number will be 1, 2, 3 ...
until the number of MIPs along the forward direction of the path.
The backward number will also be 1, 2, 3 ... until the number of
MIPs along the backward direction of the path. The forward number
Ji, et al. Expires March 4, 2010 [Page 7]
Internet-Draft MTSL September 2009
and backward number will only be available in this path. In fact,
these two numbers also mean the number of MIPs from the MEP to the
MIP.
After the numbering, when an MIP receives an OAM packet addressed to
itself, that is to say, the packet get TTL expiration at this MIP
and the GAL is found just below the current label, and need to reply,
it will refer to the TTL LFIB and perform the label swapping for the
reply. As a result, the upper part of the OAM packet trace follows
the forward/backward path and the lower part of the OAM packet trace
follows the backward/forward path.
The TTL value of the top label of the reply message is set to the
forward number or the backward number according to the incoming
label. Therefore, the message will also get TTL expiration at the
target MEP, which could be distinguished from a normal OAM message
sent by the peer MEP. Also, the message will include a special ACH
TLV to indicate which MIP sends out the message.
The paths of an LSR can be distinguished by the incoming label alone
because the label merging is forbidden in the MPLS-TP networks. This
is a basic requirement of the mechanism introduced in this document.
When the bidirectional path is revoked, the information in the TTL
LFIB also needs to be deleted just as the information in the LFIB.
5. Related ACH TLV Format
This document has mentioned four kinds of messages, a path numbering
request message, a confirmation request message, a confirmation
message, a path numbering reply message. The path numbering request
message is flagged by the MTSL and has its own special process
procedure. Other three are normal OAM packets. They abide by the
format defined in [6] and [7]. Their formats are shown in Figure 3.
Ji, et al. Expires March 4, 2010 [Page 8]
Internet-Draft MTSL 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP or PW Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP or PW Label | TC |F| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 The Format of the Three OAM Messages
The Channel Type field indicates the type of message carried on the
associated control channel. Here a new channel type definition is
needed because IP is not used as the multiplexer.
In applications of this document, the three OAM messages all have a
TTL value specially assigned at the top of the label stack and also
a special ACH TLV to indicate the source information. Here three
different ACH TLV types need to be allocated for the three messages,
and also an ACH TLV type for the MIP addressing in the OAM
communication after the path numbering need to be allocated. Its
format is the same as the former three shown in Figure 3.
These four kinds of TLV all have a TLV length value of 4. The value
part is an MPLS label. The F bit stands for whether the message is a
success message or not.
5.1. The confirmation request message
After the peer MEP receives the MTSL message, it will send a
confirmation request message to each MIP. The detailed format is
described below.
What the peer MEP receives is a label stack, the confirmation
request messages will be filled according to that label stack which
is called MTSLS. As said in Section 3, the MTSL will be removed
firstly.
In the first confirmation request message, the LSP or PW Label at
the top will be the label addressed to the source MEP, and the TTL
bits will be set to 1, and the label of the TLV will be copied from
the label at the top of the label stack MTSLS. This label is used to
Ji, et al. Expires March 4, 2010 [Page 9]
Internet-Draft MTSL September 2009
be beneath the MTSL. However, its F bit will be set to 1, and the
TTL bits will be set to the same as the top label. The TLV type is
set to path numbering confirmation request. After that, the label at
the top of the label stack MTSLS will be removed.
The second confirmation request message will have the same top LSP
or PW Label as the first one, and a TTL value 2. The label of the
TLV will be copied from the new top label in the label stack MTSLS.
The F bit is set to 1 and the TTL bits are set to 2, and the TLV
type is set to path numbering confirmation request. Also, current
top label in the label stack MTSLS will be removed.
This procedure will loop for MIPs number times, which is computed
before. After that, the top label of the label stack MTSLS will be
the one initialed by the source MEP.
5.2. The confirmation message
When the MIPs receive the confirmation request message, they will
notice the TLV type in the message and finish the path numbering
according to the label in the TLV of the confirmation request
message. After that, it will refer to the TTL LFIB element newly
built up to find the way back, and send a confirmation message.
In the confirmation message, LSP or PW Label at the top will be the
label found in the TTL LFIB, TTL bits will be set to backward number,
and the label of the TLV will be copied from the top label.
Meanwhile, its TLV type will be set to path numbering confirmation.
Its F bit will be set to 1 to indicate it is a success message.
5.3. The path numbering reply message
After the peer MEP receives all the confirmation messages, it will
send a success path numbering reply message to the source MEP if
they are all success ones. The detailed format is described below.
LSP or PW Label at the top will be the label addressed to the source
MEP, and the TTL value will be set to the MIP number plus one. The
label of the TLV will be copied from the new top label in the label
stack MTSLS, which is also the first label recorded. The F bit is
set to 1 and the TTL bits are set to the same to the top label. The
TLV type is set to path numbering reply.
After the source MEP receives the success path numbering reply
message, it will also update the MIP number value in this path's
maintenance information.
Ji, et al. Expires March 4, 2010 [Page 10]
Internet-Draft MTSL September 2009
If the ME has no MIP, the mechanism of this document will not be
necessary. This is easy to be discovered by the peer MEP when it
receives the MTSL message. It will set the MIP number value in this
path's maintenance information to zero and send a fail path
numbering reply message. This message will have F bit set to 0 and
TTL bits set to 1 in the label of ACH TLV. Also, the TTL of the top
label is set to 1. After receiving the fail path numbering reply
message, the source MEP will also set the MIP number value in this
path's maintenance information to zero.
6. Applicability
As talked before, the mechanism of this document can only be used in
the point-to-point co-routed bidirectional path of MPLS-TP networks.
It can be used in the environments where IP based routing and
forwarding are supported or not supported.
After the path numbering, the path will support OAM communications
between an MEP and an MIP. Thus, to test the performance with
respect to delay/jitter between an MEP and a certain MIP will not
rely on the IP based demultiplexing.
Also, this mechanism can be used combining with the BFD mechanism.
If the BFD mechanism finds the path fail, the MEP can send a message
to each MIP along the path to find the fail MIP.
7. Security Considerations
Security considerations discussed in MPLS Generic Associated Channel
[6] and MPLS Label Stack Encoding [2] apply to this document.
Further security considerations will described in future versions.
8. IANA Considerations
This document requests that IANA allocates a label value, to the
MTSL, from the pool of reserved labels, and suggests this value to
be 4.
The Channel Type allocation and the Associated Channel TLV
Registration discussed in MPLS Generic Associated Channel [6] and
Definition of ACH TLV Structure [7] apply to this document. This
document requests a new Channel Type and four new ACH TLV Types. The
ACH TLV Types are path numbering confirmation request, path
numbering confirmation, path numbering reply, and MIP addressing.
Further IANA considerations will described in future versions.
Ji, et al. Expires March 4, 2010 [Page 11]
Internet-Draft MTSL September 2009
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci,
D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC
3032, January 2001.
[3] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[4] Andersson, L., Minei, I., and B. Thomas, "LDP Specification",
RFC 5036, October 2007.
[5] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
January 2003.
[6] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[7] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D.
Ward, "Definition of ACH TLV Structure", draft-bryant-mpls-tp-
ach-tlv-02 (work in progress), May 2009.
9.2. Informative References
[8] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS
in Transport Networks", draft-ietf-mpls-tp-framework-03 (work
in progress), August 2009.
[9] IETF - ITU-T Joint Working Team, "MPLS Architectural
Considerations for a Transport Profile", April 2008,
<http://www.ietf.org/MPLS-TP_overview-22.pdf>.
[10] 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.
10. Acknowledgments
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
Ji, et al. Expires March 4, 2010 [Page 12]
Internet-Draft MTSL September 2009
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Yuefeng Ji
Beijing University of Posts and Telecommunications
P.O. Box 128, No.10, Xi Tu Cheng Road, Beijing 100876, China
Phone:
Email: jyf@bupt.edu.cn
Yueming Lu
Beijing University of Posts and Telecommunications
Phone:
Email: ymlu@bupt.edu.cn
Zongpeng Du
Beijing University of Posts and Telecommunications
Phone:
Email: duzongpeng@gmail.com
Ji, et al. Expires March 4, 2010 [Page 13]