One document matched: draft-ietf-pwe3-mpls-tp-ms-pw-00.txt
Network Working Group Siva Sivabalan (Ed.)
Internet Draft Sami Boutros (Ed.)
Intended status: Informational Luca Martini
Expires: January 1, 2012
Cisco Systems, Inc.
July 1, 2011
Stitching Procedures for Static PW in MPLS-TP Environment
draft-ietf-pwe3-mpls-tp-ms-pw-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 January 1, 2012.
This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF
Last Call.
[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.]
Sivabalan Expires January 1, 2012 [Page 1]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
Abstract
The existing procedures for concatenating static and dynamic
pseudowires (PWs) do not take into account the PW status Operation,
Administration, and Maintenance (OAM) messages defined for static PW.
Also, these procedures 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 stitching
procedures for static PW taking into account all the new proposed
extensions.
This document is a product of a joint Internet Engineering Task
Force(IETF) / International Telecommunication Union
Telecommunication Standardization Sector (ITU-T) effort to include
an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of a
packet transport network.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Operation......................................................4
3.1. Lock Operation............................................5
3.1.1. Locking MPLS-TP LSP..................................5
3.1.2. Locking PW...........................................6
3.2. Loopback Operation........................................7
3.2.1. Loopback at MPLS-TP LSP Level........................7
3.2.2. Loopback at PW Level.................................7
3.3. Switching Point PE TLV....................................8
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.........................................10
Intellectual Property Statement..................................10
1. Introduction
The PWE3 Architecture in [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].
Sivabalan Expires January 1, 2012 [Page 2]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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 MS-PW in an
MPLS Transport Profile (MPLS-TP) environment. These functions enable
network operators to lock a circuit (LSP and PW) and operate it in
loopback mode for testing/management purpose.
This informational document describes the application of the existing
PW stitching procedures taking into consideration LI, LB, as well as
PW status OAM messages.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
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 [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.
Sivabalan Expires January 1, 2012 [Page 3]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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
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
Sivabalan Expires January 1, 2012 [Page 4]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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 is 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 an LI request for the MPLS-TP LSP
carrying PW1. The intended recipient of the message will be the S-PE.
When T-PE1 receives a positive LI reply from the 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.
When S-PE receives an LI request, if the intended MPLS-TP LSP can be
locked, the S-PE finds all PWs associated with this MPLS-TP LSP and
first sends the PW status code 0x00000018 (Local PSN-facing PW
Receive/Transmit Faults) on all stitched PWs segments 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. 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.
Sivabalan Expires January 1, 2012 [Page 5]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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 PW1 as well as all other
PWs pinned down to MPLS-TP LSP in question to T-PE1 and PW2 and all
other stitched PWs other segments 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-PE1 and T-PE2 so that services on PW1 and PW2
and all other PWs associated with the MPLS-TP LSP in question can
resume.
If PW2 is a dynamic segment and PW status, S-PE needs to withdraw its
labels from T-PE1 and 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.
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. S-PE is the intended recipient (based on the TTL value
of the PW label).If S-PE 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
Sivabalan Expires January 1, 2012 [Page 6]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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.
.
3.2. Loopback Operation
3.2.1. 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, and 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. 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
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.
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
Sivabalan Expires January 1, 2012 [Page 7]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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.
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].
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.
Sivabalan Expires January 1, 2012 [Page 8]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
[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-status-00.txt (work in
progress), February 2010.
[5] Sami Boutros, et. al, "MPLS Transport Profile Lock Instruct and
Loopback Functions", draft-ietf-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-ietf-mpls-tp-lsp-ping-extensions-01.txt (work in
progress), February 2010.
Author's Addresses
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: msiva@cisco.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
United States
Email: lmartini@cisco.com
Sivabalan Expires January 1, 2012 [Page 9]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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.
Sivabalan Expires January 1, 2012 [Page 10]
Internet-Draft draft-ietf-pwe3-mpls-tp-ms-pw-00.txt July 2011
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.
Sivabalan Expires January 1, 2012 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 10:52:00 |