Internet DRAFT - draft-hart-pwe3-segmented-pw-vccv
draft-hart-pwe3-segmented-pw-vccv
Network Working Group Neil Hart
Internet Draft Mustapha Aissaoui
Expires: May 2008 Matthew Bocci
Tiberiu Grigoriu
Michael Hua
Alcatel-Lucent
November 18, 2007
VCCV Extensions for Segmented Pseudo-Wire
draft-hart-pwe3-segmented-pw-vccv-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 18, 2008.
Abstract
This document describes extensions to Single Hop Virtual Circuit
Connectivity Verification (SH-VCCV) procedures for segmented pseudo
wires to test the end-to-end forwarding datapath and to provide a MS-
PW segment trace capability. This is accomplished by changing the
adaptation function for the Single Hop VCCV parameter at the
switching point between two distinct PW control planes.
Hart et al. Expires May 18, 2008 [Page 1]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
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.
Table of Contents
1. Terminology....................................................2
2. Introduction...................................................3
3. Adaptation of the Single-Hop CW VCCV for end to end verification4
3.1. VCCV Capability Signaling for MS-PW.......................4
3.2. End-to-end VCCV...........................................5
3.3. Partial tracing from T-PE.................................5
3.4. Partial Tracing between S-PEs.............................6
3.5. Automated VCCV Trace from T-PE............................6
4. Control Plane Processing of an VCCV Echo Message in a MS-PW....6
4.1. Sending a VCCV Echo Request...............................7
4.2. Receiving an VCCV Echo Request............................7
4.3. Receiving an VCCV Echo Reply..............................7
4.4. VCCV Trace Operations.....................................8
5. Security Considerations........................................9
6. IANA Considerations............................................9
7. Acknowledgments................................................9
8. References.....................................................9
8.1. Normative References......................................9
8.2. Informative References....................................9
Author's Addresses................................................9
Full Copyright Statement.........................................10
Intellectual Property Statement..................................11
Acknowledgment...................................................11
1. Terminology
- PW Terminating Provider Edge (T-PE). A PE where the customer-
facing attachment circuits (ACs) are bound to a PW forwarder. A
Terminating PE is present in the first and last segments of a MS-PW.
This incorporates the functionality of a PE as defined in [RFC3985].
- Single-Segment Pseudo Wire (SS-PW). A PW setup directly between two
T-PE devices. Each PW in one direction of a SS-PW traverses one PSN
tunnel that connects the two T-PEs.
- Multi-Segment Pseudo Wire (MS-PW). A static or dynamically
configured set of two or more contiguous PW segments that behave and
Hart et al. Expires May 18, 2008 [Page 2]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
function as a single point-to-point PW. Each end of a MS-PW by
definition MUST terminate on a T-PE.
- PW Segment. A part of a single-segment or multi-segment PW, which
is set up between two PE devices, T-PEs and/or S-PEs.
- PW Switching Provider Edge (S-PE). A PE capable of switching the
control and data planes of the preceding and succeeding PW segments
in a MS-PW. The S-PE terminates the PSN tunnels of the preceding and
succeeding segments of the MS-PW.
- PW switching point for a MS-PW. A PW Switching Point is never the
S-PE and the T-PE for the same MS-PW. A PW switching point runs
necessary protocols to setup and manage PW segments with other PW
switching points and terminating PEs.
2. Introduction
Virtual Circuit Connectivity Verification (VCCV) allows network
operators to test the forwarding datapath of pseudo wire (PW)
services. As pseudo wires are extended to cover multiple segments, it
is required to be able to continue operating VCCV end-to-end across a
switching point and to provide the ability to trace the path of the
multi-segment PW (MS-PW) over any number of segments.. Figure 1
illustrates a multi-segment pseudo wire providing connectivity from
T-PE1 to T-PE2 through the switching point S-PE. By suitable
implementation at the S-PEs and with no modification to the T-PE
single-segment PW (SS-PW) implementation, VCCV can be simply extended
to provide both end to end and segment connection verification.
Native |<-----------Pseudo Wire----------->| Native
Layer2 | | Layer2
Service | |<-PSN1-->| |<--PSN2->| | Service
(AC) V V V V V V (AC)
| +----+ +-----+ +----+ |
+----+ | | |=========| |=========| | | +----+
| |----------|........PW1.........|...PW3........|----------| |
| CE1| | | | | | | | | |CE2 |
| |----------|........PW2.........|...PW4........|----------| |
+----+ | |=========| |=========| | +----+
^ +----+ +-----+ +----+ ^
| T-PE1 S-PE T-PE2 |
| |
|<------------------- Emulated Service -------->|
Figure 1 MS-PW Service
Hart et al. Expires May 18, 2008 [Page 3]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
The method proposed in this document adapts the SS-PW Control Word
method such that S-PE nodes decrement the TTL in the PW label and
pass forward the VCCV packet to the next segment of the PW. Packets
for which the TTL expires have their payload examined and are
identified as VCCV packets due to the presence of the CW. They are
then diverted to the control plane for further processing. This
method is a variant to the one described in [PWE3-MS] which is based
on defining a new VCCV sub-TLV in the optional PW switching point
TLV. The advantages of the proposed method are that it limits the
processing of the VCCV packet payload only to the S-PE/T-PE node
which is the target for the message. All other S-PE nodes in between
are not required to inspect the VCCV CW and are only required to
decrement the TTL of the PW label. Also, this method does not require
upgrading the SS-PW CW method supported by T-PE nodes. Finally, it
provides a model of operation consistent with the operation of MPLS
LSP Ping and LSP Trace.
3. Adaptation of the Single-Hop CW VCCV for end to end verification
3.1. VCCV Capability Signaling for MS-PW
In Figure 1 T-PE1 uses the VCCV parameter included in the interface
parameter field of the PW ID FEC TLV or the sub-TLV interface
parameter of the Generalized PW ID FEC TLV to indicate to the far end
T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV
parameter as would be used if T-PE1 and T-PE2 were connected directly
by T-LDP. S-PE, which is a PW switching point, as part of the
adaptation function for interface parameters, processes locally the
VCCV parameter then passes it to T-PE2. If there were multiple S-PEs
on the path between T-PE1 and T-PE2, each would carry out the same
processing, passing along the VCCV parameter.
The local processing of the VCCV parameter removes CC Types specified
by the originating T-PE, except PWE3 Control Word that is passed
unchanged. In other words, VCCV for MS-PW will not support other CC
types, i.e., TTL=1 and Router Alert. For example, if T-PE1 indicates
as supported CC Types both Control Word and Router Alert then the S-
PE removes the Router Alert CC Type, leaving Control Word CC Type
unchanged and then passes the modified VCCV parameter to the next S-
PE along the path.
The far end T-PE (T-PE2) receives the VCCV parameter indicating the
Control Word CC Type only if that is supported by the initial T-PE
(T-PE1) and all S-PEs along the PW path. In that case, T-PE2 knows
that T-PE1 is capable of receiving the CW CC type and that each S-PE
node in the path of the MS-PW is capable of relaying and generating/
terminating the VCCV messages.
Hart et al. Expires May 18, 2008 [Page 4]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
3.2. End-to-end VCCV
In Figure 1, if T-PE1, S-PE and T-PE2 support Control Word for VCCV,
then as described in section 3.1. the control plane negotiates the
common use of Control Word for VCCV end to end.
Thus, the end-to-end connectivity of the multi-segment pseudowire can
be verified as follows:
a) T-PE forms an MPLS echo request message with the FEC matching
that of the last segment PW to the destination T-PE. In Figure 1,
this would be the FEC of segment PW3 for example. See Section 4.
for details on how this FEC is obtained by T-PE1.
b) T-PE sets inner PW label TTL to a large enough value to allow the
packet to reach the far end T-PE
c) T-PE sends a VCCV packet that will follow the exact same data
path at each S-PE as that taken by data packets,
d) S-PE performs an outer label pop, an inner label swap with TTL
decrement, and new outer label push.
e) there is no requirement for the S-PE to inspect the CW
f) VCCV packet is diverted to VCCV control processing at the
destination T-PE
g) Destination T-PE replies using the specified reply mode, i.e.,
reverse PW path or IGP path
3.3. Partial tracing from T-PE
In order to trace part of the multi-segment pseudowire, the TTL of
the PW label may be used to force the VCCV message to 'pop out' at an
intermediate node. When the TTL expires, the S-PE can determine that
the packet is a VCCV packet by checking the control word. If the
control word format matches that specified in [VCCV], the packet
should be diverted to VCCV processing.
In Figure 1, if T-PE1 sends a VCCV message with the TTL of the PW
label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus
verify the first segment of the pseudo wire.
Note that this use of the TTL is subject to the caution expressed in
[VCCV]. If a penultimate LSR between S-PEs or between an S-PE and a
Hart et al. Expires May 18, 2008 [Page 5]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
T-PE manipulates the PW label TTL, the VCCV message may not emerge
from the MS-PW at the correct S-PE.
3.4. Partial Tracing between S-PEs
Assuming that all nodes along an MS-PW support the Control Word CC
Type, VCCV between S-PEs may be accomplished using the PW label TTL
as in section 3.3. In Figure-1, the S-PE may verify the path between
it and T-PE2 by sending a VCCV message with the PW label TTL set to
1. Given a more complex network with multiple S-PEs, an S-PE may
verify the connectivity between it and an S-PE two segments away by
sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE
can diagnose connectivity problems by successively increasing the TTL.
3.5. Automated VCCV Trace from T-PE
Although tracing of the MS-PW path is possible using the methods
explained in sections 3.3. and 3.4. , these require multiple manual
iterations and that the FEC of the last PW segment to the target T-
PE/S-PE be known a priori at the node originating the echo request
message for each iteration. This mode of operation will be referred
to as the "ping" mode.
A full automated path tracing capability that iteratively probes the
segments the MS-PW to learn the target FEC information is required.
This will be referred to as the "trace" mode of operation. The
details of this method are described in Section 4.4.
4. Control Plane Processing of an VCCV Echo Message in a MS-PW
The challenge for the control plane is to be able to build the VCCV
echo request packet with the necessary information such as the target
FEC 128 PW sub-TLV (FEC128) of the downstream PW segment which the
packet is destined for. This could be even more difficult in
situations in which the MS-PW spans different providers and
Autonomous Systems.
For example, in Figure 1, T-PE1 has the required information to
compose the FEC128 of the PW1 segment but it does not readily have
the information required to compose the FEC128 of the PW3 segment if
a VCCV echo request is supposed to be destined to T-PE2. This
challenge can be overcome by the methods described in the following
subsections 4.1. , 4.2. and 4.4. .
Hart et al. Expires May 18, 2008 [Page 6]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
4.1. Sending a VCCV Echo Request
When in the "ping" mode of operation, the sender of the echo request
message requires the FEC of the last segment to the target S-PE/T-PE
node. This information can either be configured manually or be
obtained by inspecting the corresponding sub-TLV's of the PW
switching point TLV. However, the PW switching point TLV is optional
and there is no guarantee that all S-PE nodes will populate it with
their system address and the PWid of the last PW segment traversed by
the label mapping message. Thus a manual configuration is always
preferred.
When in the "trace" mode operation, the T-PE will automatically learn
the target FEC by probing one by one the hops of the MS-PW path. Each
S-PE node includes the FEC to the downstream node in the echo reply
message in a similar way that LSP trace will have the probed node
return the downstream interface and label stack in the echo reply
message. The details of this method are described in the following
sections.
4.2. Receiving an VCCV Echo Request
Upon receiving a VCCV echo request the control plane on S-PEs (or the
target node of each segment of the MS-PW) validates the request and
responds to the request with an echo reply consisting of the FEC128
of the next downstream segment and a return code of 8 (label switched
at stack-depth) indicating that it is an S-PE and not the egress
router for the MS-PW.
If the node is the T-PE or the egress node of the MS-PW, it responds
to the echo request with an echo reply with a return code of 3
(egress router) and no FEC128 is included.
4.3. Receiving an VCCV Echo Reply
The operation to be taken by the node that receives the echo reply in
response to its echo request depends on its current mode of operation
such as "ping" or "trace".
In "ping" mode, the node may choose to ignore the target FEC128 in
the echo reply and report only the return code to the operator.
However, in "trace" mode, the node builds and sends the subsequent
VCCV echo request with a incrementing TTL and the information (such
as the downstream FEC128) it received in the echo request to the next
downstream PW segment.
Hart et al. Expires May 18, 2008 [Page 7]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
4.4. VCCV Trace Operations
As an example, in Figure 1, VCCV trace can be performed on the MS-PW
originating from T-PE1 by a single operational command. The following
process ensues:
1. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC128
containing the pseudo-wire information of the first segment (PW1
between T-PE1 and S-PE) to S-PE for validation. If FEC Stack
Validation is enabled, the request may also include additional
subTLV such as LDP Prefix and/or RSVP LSP dependent on the type
of transport tunnel the segmented PW is riding on.
2. S-PE validates the echo request with the FEC128. Since it is a
switching point between the first and second segment it builds an
echo reply with a return code of 8 and includes the FEC128 of the
second segment (PW3 between S-PE and T-PE2) and sends the echo
reply back to T-PE1. If FEC stack validation is requested the
S-PE validates the received FEC stack and builds the echo reply
with the downstream target FEC stack which includes FEC128 subTLV
and any addition target FEC stack subTLVs required for the next
hop FEC stack validation.
3. T-PE1 builds a second VCCV echo request based on the target FEC
stack in the echo reply from the S-PE. It increments the TTL and
sends the next echo request out to T-PE2. Note that the VCCV echo
request packet is switched at the S-PE datapath and forwarded to
the next downstream segment without any involvement from the
control plane.
4. T-PE2 receives and validates the echo request with the FEC128, or
the target FEC stack if the FEC stack validation is required, of
the PW3 from T-PE1. Since T-PE2 is the destination node or the
egress node of the MS-PW it replies to T-PE1 with an echo reply
with a return code of 3 (Egress Router) and no FEC128 is
included.
5. T-PE1 receives the echo reply from T-PE2. T-PE1 is made aware
that T-PE2 is the destination of the MS-PW because the echo reply
does not contain the FEC128 and because its return code is 3. The
trace process is completed.
Note that the above example assumes only FEC128 sub-TLV is exchanged
but it is possible that the exchanged information could also involve
other TLV or Target FEC sub-TLVs (such as FEC129, LDP Prefix or RSVP
LSP). For more detail on the format of the VCCV echo packet, refer to
[VCCV] and [RFC4379]. The TTL here refers to that of the inner (VC)
Hart et al. Expires May 18, 2008 [Page 8]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
label TTL but it is also possible that the methods described in this
section could use the MH-TTL as described in [PW3-MS].
5. Security Considerations
Same as security concerns described in [VCCV].
6. IANA Considerations
All the values of the CC, CV and channel types are as described in
[VCCV].
7. Acknowledgments
The authors would like to thank Vach Kompella and Kendall Harvey for
their valuable comments and suggestions.
8. References
8.1. Normative References
[VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
Verification (VCCV)", draft-ietf-pwe3-vccv-15.txt, September
2007.
[PWE3-MS] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-
pwe3-segmented-pw-05.txt, July 2007.
[RFC4379] Kompella, K., et al., "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC4379, February
2006.
8.2. Informative References
Author's Addresses
Neil Hart
Alcatel-lucent
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: neil.hart@alcatel-lucent.com
Hart et al. Expires May 18, 2008 [Page 9]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
Tiberiu Grigoriu
Alcatel-lucent
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: tiberiu.grigoriu@alcatel-lucent.com
Mustapha Aissaoui
Alcatel-lucent
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: mustapha.aissaoui@alcatel-lucent.com
Matthew Bocci
Alcatel-lucent
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks, UK SL6 2PJ
Email: matthew.bocci@alcatel-lucent.co.uk
Michael Hua
Alcatel-lucent
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: michael.hua@alcatel-lucent.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Hart et al. Expires May 18, 2008 [Page 10]
Internet-Draft Segmented Pseudo Wire VCCV November 2007
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. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR 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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hart et al. Expires May 18, 2008 [Page 11]
