Internet DRAFT - draft-boutros-pwe3-ms-pw-tp
draft-boutros-pwe3-ms-pw-tp
Network Working Group Siva Sivabalan (Ed.)
Internet Draft Sami Boutros (Ed.)
Intended status: Informational Luca Martini
Expires: January 5, 2011
Cisco Systems, Inc.
July 5, 2010
Pseudowire Stitching Procedures in MPLS-TP Networks
draft-boutros-pwe3-ms-pw-tp-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 Jaunary 5, 2011.
Abstract
The existing procedures for concatenating Pseudowire(PW) segments to
form Multi-Segment PW (MS-PW) do not take into account operator
functions such Lock Instruct and Loopback introduced as part of MPLS
Transport Profile (MPLS-TP). This informational document reiterates
the PW stitching procedures in an MPLS-TP environment.
Boutros Expires January 5, 2011 [Page 1]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Operation......................................................3
3.1. Lock Operation............................................4
3.1.1. Locking MPLS-TP LSP..................................4
3.1.2. Locking PW...........................................6
3.2. Loopback Operation........................................6
3.2.1. Loopback at MPLS-TP LSP Level........................6
3.2.2. Loopback at PW Level.................................7
3.3. Switching Point PE TLV....................................7
3.4. LSP-Ping/Trace............................................8
4. Security Considerations........................................8
5. IANA Considerations............................................8
6. References.....................................................8
6.1. Normative References......................................8
6.2. Informative References....................................8
Author's Addresses................................................9
Full Copyright Statement..........................................9
Intellectual Property Statement..................................10
1. Introduction
The PWE3 Architecture [1] defines signaling and encapsulation
techniques for establishing Single Segment PW (SS-PW) between a pair
of terminating PEs. Procedures for stitching two or more static or
dynamic SS-PWs to form Multi-Segment PW (MS-PW) are described in [2].
These procedures make use of PW status messages carried in LDP TLV
over dynamic PW established via LDP. [3] defines a new PW status OAM
message used to carry PW status in-band over static PW. This message
makes it possible to exchange PW status end-to-end over a MS-PW
consisting of one or more static PW.
[5] specifies operator new Operation, Administration, and Maintenance
(OAM) functions Lock Instruct (LI) and Loopback (LB) for associated
bi-directional circuits such as MPLS-TP LSP, SS-PW, and M-PW in an
MPLS Transport Profile (MPLS-TP) environment. These functions enable
network operators to lock a circuit and operate it in loopback mode
for testing/management purpose. LSP and PW.
This informational document describes the application of the existing
PW stitching procedures taking into consideration LI, LB, as well as
PW status OAM messages.
Conventions used in this document
Boutros Expires January 5, 2011 [Page 2]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
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].
2. Terminology
LDP: Label Distribution Protocol.
MEP: Maintenance End Point.
MIP: Maintenance Intermediate Point.
MPLS: Multi Protocol Label Switching.
MPLS-TP: MPLS Transport Profile.
MS-PW: Multi-Segment PseudoWire.
LB: Loopback.
LI: Lock Instruct.
LSP: Label Switched Path.
OAM: MPLS Operations, Administration and Maintenance.
PE: Provide Edge Node.
PW: PseudoWire.
S-PE: Switching Provider Edge Node of a MS-PW.
SS-PW: Single-Segment PseudoWire.
TLV: Type, Length, and Value.
T-PE: Terminating Provider Edge Node of a MS-PW.
3. Operation
In this section, we explain the use of LI/LB mechanisms referring
to the MS-PW model shown in Figure 1. The SS-PW segments PW1 and PW2
can be either static or dynamic. We assume that PWs are carried over
MPLS-TP LSPs (transport LSPs) so that LI/LB mechanisms can be applied
Boutros Expires January 5, 2011 [Page 3]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
at the transport LSP level, as well we consider the application of
LI/LB at PW level.
PW status is sent via LDP message and PW OAM message respectively
over dynamic and static PW segments. Note that even though only two
PW segments are considered in the examples below, the described
procedures are applicable to MS-PWs with more than two segments.
+-------+ (PW1) +-------+ (PW2) +-------+
| |------------->| |-------------->| |
| T-PE1 | | S-PE | | T-PE2 |
| |<-------------| |<--------------| |
+-------+ +-------+ +-------+
Figure 1. Reference Model for LI/LB Mechanism
3.1. Lock Operation
3.1.1. Locking MPLS-TP LSP
An MPLS-TP LSP can be taken out of service for maintenance operation
using the LI mechanism described in [5]. LI messages are exchanged
between MPLS-TP Maintenance End Points (MEPs). In the case of MS-PW,
each MPLS-TP LSP associated with a given PW segment can be
individually locked for management purpose. This means that, in a MS-
PW scenario, a T-PE is always a MEP and an S-PE can either be a MIP
or a MEP for an MPLS-TP LSP carrying PW segments. Furthermore, a T-PE
(MEP) assumes that an MPLS-TP LSP is successfully locked only when
the corresponding LI reply is received from the other intended
receiver MEP (other T-PE or S-PE).
3.1.1.1. LI originated at T-PE
Assume that T-PE1 originates LI request for the MPLS-TP LSP carrying
PW1. The intended recipient of the message can be either S-PE or T-
PE2. When T-PE1 receives positive LI reply from the intended
recipient (T-PE2 or S-PE), it assumes that the MPLS-TP LSP is
successfully locked, and takes PW1 and all other PWs associated with
the MPLS-TP LSP out of service. This means that PW1 and all other
impacted PWs will no longer carry user data.
If S-PE receives an LI request, and if the intended MPLS-TP LSP can
be locked, it first sends the following PW status code 0x00000018
(Local PSN-facing PW Receive/Transmit Faults) to T-PE2. Note that the
same PW status code will be sent for all PWs associated with the MPLS
Boutros Expires January 5, 2011 [Page 4]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
LSP being locked out. PW status code is sent over PW OAM message or
LDP message depending on whether the segment PW2 is static or
dynamic. After sending the PW status code to T-PE2, S-PE lock the
MPLS-TP LSP and sends a positive LI reply to T-PE1. If the MPLS-TP
LSP cannot be locked, S-PE sends a negative LI reply with the
appropriate error code to T-PE1.
When T-PE2 receives the PW status codes, it processes them as
described in [3] or [4] depending on whether PW2 is dynamic or
static.
If PW2 is a dynamic segment and does not support PW status, S-PE
needs to withdraw its labels from T-PE2 before locking the MPLS LSP.
For better scalability, S-PE may use the notion of group ID described
in [6] to send PW status or withdraw labels all impacted dynamic PWs
between itself and T-PE2. Use of group ID with PW status OAM over
static PW is TBD (Sami: Check).
3.1.1.2. LI originated at S-PE
Let's assume that an operator wants to originate an LI request at S-
PE for the MPLS-TP LSP carrying PW1. The intended recipient of the LI
request is T-PE1. First, S-PE sends PW status code 0x00000018 (Local
PSN-facing PW Receive/Transmit Fault) for PW2 as well as all other
PWs pinned down to MPLS-TP LSP in question to T-PE2. PW status code
is sent over PW OAM message or LDP message depending on whether the
segment PW2 is static or dynamic. When T-PE2 receives the PW status
codes, it processes them as described in [3] or [4] respectively
depending on whether PW2 is dynamic or static. It then sends LI
request message to T-PE1. If T-PE1 can successfully lock the MPLS
LSP, it sends a positive LI response. Upon receiving the response, S-
PE1 assumes that the MPLS-TP LSP is locked, and PW1 is no longer used
for carrying regular user data.
If T-PE1 is unable to lock the MPLS-TP LSP, it sends a negative LI
response with the appropriate error code. In this case, S-PE sends PW
status 0x00000000 to T-PE2 so that services on PW2 can resume.
If PW2 is a dynamic segment and PW status, S-PE needs to withdraw its
labels from T-PE2 before sending LI request to T-PE1.
For better scalability, S-PE may use the notion of group ID described
in [6] to send PW status or withdraw labels all impacted dynamic PWs.
Use of group ID with PW status OAM over static PW is TBD.
Boutros Expires January 5, 2011 [Page 5]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
3.1.2. Locking PW
A given PW can also be taken out of service for maintenance operation
without impacting services over other PWs using the LI mechanism
described in [5].
3.1.2.1. LI originated at T-PE
In our example, let's assume that, T-PE1 sends an LI request message
to lock PW1. If S-PE is the intended recipient (based on the TTL
value of the PW label) and if it is able to lock PW1, it sends a PW
status message with the status code 0x00000018 (Local PSN-facing PW
Receive/Transmit Fault) over PW2 to T-PE2, and locks PW1. S-PE then
sends a positive LI reply to T-PE1. Upon receiving the positive LI
reply, T-PE locks PW1. If S-PE is unable to lock PW1, it sends a
negative LI reply to T-PE1. PW status code is sent over PW OAM
message or LDP message depending on whether the segment PW2 is static
or dynamic. When T-PE2 receives the PW status codes, it processes
them as described in [3] or [4] depending on whether PW2 is dynamic
or static.
If T-PE2 is the intended recipient of the LI message (in this case S-
PE is a MIP), and if T-PE2 is able to lock PW2, it locks PW2 and
sends a positive LI response to T-PE1. If T-PE2 is unable to lock
PW2, it sends a negative LI response to T-PE1. Note that TTL value of
the PW label in the LI response should be chosen (e.g., 255) such
that the LI response will not be intercepted and processed by any
node other than T-PE1.
3.2. Loopback Operation
As described in [5], an MPLS-TP LSP or a PW can be setup to in
loopback mode for management purpose, e.g., to test or verify
connectivity of the LSP/PW up to a specific node on the path of the
MPLS-TP tunnel/PW, to test the LSP/PW performance with respect to
delay/jitter, etc. But, prior to operating in loopback mode, an MPLS-
TP LSP or PW must be successfully locked.
3.2.1. Loopback at MPLS-TP LSP Level
Assume that an operator wants to operate an MPLS-TP LSP between T-PE1
and S-PE carrying PW1 in loopback mode such that S-PE loops all the
incoming packets over the MPLS-TP LSP back to the sender (in this
case T-PE1).
T-PE1 sends an LB request message which is received by S-PE. S-PE can
setup the MPLS-TP LSP only if all the PWs carried over that LSP can
Boutros Expires January 5, 2011 [Page 6]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
be setup in loopback mode. If S-PE can setup the MPLS-TP tunnel in
loopback mode, it sends a positive LB response. Otherwise, it sends a
negative LB response to T-PE1.
If the MPLS-TP LSP is successfully setup in loopback mode, all
incoming packets over PW1 will be looped back to T-PE1. This is also
true for any other PW(s) between T-PE1 and S-PE pinned down to the
MPLS-TP LSP in question.
Similarly, MPLS-TP LSP between S-PE and T-PE1 can be operated in
loopback mode such that T-PE1 loops all incoming packets over the LSP
back to S-PE. In this case, S-PE and T-PE1 respectively are sender
and receiver of the LB request message.
The loopback operation can as well be between T-PE1 and T-PE2, in
this case PW2 and all PWs pinned down over the MPLS-TP LSP (that
received the LB request) will be programmed to loopback traffic back
to T-PE1.
3.2.2. Loopback at PW Level
A SS-PW or MS-PW can be operated in loopback mode.
In our example, let's assume that PW1 is to be operated in a loopback
mode such that S-PE loops all incoming packets over PW1 back to T-
PE1. To setup this mode of operation, T-PE1 sends an LB request
message to S-PE. TTL value of the PW label is chosen so as to expire
on the intended recipient (in our example TTL value should be 1 so
that LB request can be processed at S-PE). If S-PE can successfully
setup PW1 in loopback mode, it sends a positive LB response to T-PE1.
If loopback operation over the entire MS-PW (i.e., over PW1 and PW2)
such that T-PE2 loops all the incoming packets over PW2 back to T-
PE1, T-PE1 and T-PE2 will be the sender and receiver of LB message.
3.3. Switching Point PE TLV
Switching Point PE TLV (S-PE TLV) is used to record information about
S-PE(s) that a PW traverses. An S-PE TLV contains many sub-TLVs as
described in [3]. One such sub-TLV carries the FEC of the last
traversed PW segment defined for FEC129.
In the case of MS-PW containing static PW segment(s), if the last
traversed PW segment is statically provisioned, a new sub-TLV
containing the FEC defined for static PW in [7] can be used to
represent the last traversed PW segment. The new sub-TLV type will be
defined in [4].
Boutros Expires January 5, 2011 [Page 7]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
3.4. LSP-Ping/Trace
TBD
4. Security Considerations
This document does not introduce any additional security constraints.
5. IANA Considerations
Not applicable.
6. References
6.1. Normative References
[1] Bradner. S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
6.2. Informative References
[2] Stewart Bryant, et. al, "Pseudowire Emulation Edge-to-Edge
(PWE3) Architecture", RFC3985, March 2005.
[3] Luca Martini, et. al, "Segmented Pseudowire", draft-ietf-pwe3-
segmented-pw-15.txt (work in progress), June 2010.
[4] Luca Martini, et. al, "Pseudowire Status for Static
Pseudowires", draft-ietf-pwe3-static-pw-statuc-00.txt (work in
progress), February 2010.
[5] Sami Boutros, et. al, "MPLS Transport Profile Lock Instruct and
Loopback Functions", draft-boutros-mpls-tp-li-lb-00.txt (work
in progress), June 2010.
[6] Luca Martini, et. al, "Pseudowire Setup and Maintenance Using
Label Distribution Protocol (LDP)", RFC4447, April 2006.
[7] Nitin Bahadur, et. al, "LSP-Ping extensions for MPLS-TP",
draft-nitinb-mpls-tp-lsp-ping-extensions-01.txt (work in
progress), February 2010.
Boutros Expires January 5, 2011 [Page 8]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
Author's Addresses
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: msiva@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
United States
Email: lmartini@cisco.com
Full Copyright Statement
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.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Boutros Expires January 5, 2011 [Page 9]
Internet-Draft draft-boutros-pwe3-ms-pw-tp-00.txt July 2010
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the UETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boutros Expires January 5, 2011 [Page 10]
