One document matched: draft-dong-pwe3-mspw-oam-00.txt
PWE3 Working Group Jixiong Dong
Internet Draft Huawei Technologies Co., Ltd.
Expires: April 2006 October 10, 2005
Operation and Maintenance for Multi-segment Pseudo Wire
draft-dong-pwe3-mspw-oam-00.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/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 April 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This draft proposes a method for operation and maintenance on the
multi-segment pseudo wires (MS-PWs). It extends and is compatible
with the existing single-segment pseudo wire OAM mechanism [VCCV].
Dong Expires April 10, 2006 [Page 1]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
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. Introduction...............................................2
2. Reference Model for MS-PW OAM..............................3
3. MS-PW OAM functions........................................4
3.1. Segment OAM and End-to-end OAM........................4
3.2. Fault Notification....................................5
3.3. OAM Extension.........................................7
3.3.1. Inband VCCV Extension............................7
3.3.2. Out-of-band VCCV Extension.......................8
3.3.3. Expiry TTL VCCV Extension........................8
4. OAM Capability Indication for Multi-segment PW using MPLS..9
4.1. Introduction..........................................9
5. MS-PW OAM procedures in IP PSN.............................10
5.1. L2TPv3 VCCV FDI AVP Message...........................10
5.2. L2TPv3 VCCV Capability Indication AVP Message.........10
6. Security Considerations....................................11
7. Acknowledgments............................................11
8. References.................................................11
8.1. Normative References..................................11
8.2. Informative References................................12
9. Author's Addresses.........................................12
10. Intellectual Property Statement...........................12
Disclaimer of Validity........................................13
Copyright Statement...........................................13
Acknowledgment................................................13
1. Introduction
One pseudo-wire may reach across more than one packet switched
network (PSN) domain and more than one PSN tunnel. These pseudo-wires
are called multi-segment pseudo-wires (MS-PW). One pseudo-wire may
exist in only one packet switched network (PSN) domain and only one
PSN tunnel. These pseudo-wires are called single-segment pseudo-wires
(SS-PW).
The interworking of operation and maintenance (OAM) mechanisms for
SS-PWs between ACs and PWs is defined in [OAMMAP], which enables
defect states to be propagated across a PWE3 network. OAM mechanisms
for MS-PWs MUST provide at least the same capabilities as those for
Dong Expires April 10, 2006 [Page 2]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
SS-PWs, i.e., which must comply with SS-PW OAM mechanisms. In
addition, it should be possible to support the other OAM requirements
described in [MSPWREQ].
This draft extends the VCCV mechanism described in [VCCV] to
implement MS-PW OAM functions. To support FDI function, new FDI
payload packet type is introduced.
2. Reference Model for MS-PW OAM
The figure below describes PW switching reference model [MSPWREQ].
Native |<-----------Pseudo Wire----------->| Native
Service | | Service
(AC) | |<-PSN1-->| |<--PSN2->| | (AC)
| V V V V V V |
| +----+ +-----+ +----+ |
+----+ | | PE1|=========| PE2 |=========| PE3| | +----+
| |----------|........PW1.........|...PW3........|----------| |
| CE1| | | | | | | | | |CE2 |
| |----------|........PW2.........|...PW4........|----------| |
+----+ | | |=========| |=========| | | +----+
^ +----+ +-----+ +----+ | ^
| Provider Edge 1 ^ Provider Edge 3 |
| | |
| | |
| PW switching point |
| |
| |
|<------------------- Emulated Service ------------------>|
Figure 1 PW switching Reference Model
One MS-PW may consist of multiple SS-PWs and can be regarded as one
logical pseudo wire. Each of the single SS-PW can be regarded as one
individual physical link. From layer network point of view, MS-PW is
a client sublayer and SS-PW is the server sublayer. Thus, the
reference model above can be illustrated by the following figure.
Dong Expires April 10, 2006 [Page 3]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
+----+ +-----+ +-----+ +----+
+----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+
| |-----|...................MS-PW....................|-----| |
| CE1| | | | | | | | | |CE2 |
| |-----|-------PW1----------PW2------------PW3------|-----| |
+----+ | |======| |=======| |=======| | +----+
+----+ +-----+ +-----+ +----+
Figure 2 MS-PW layered reference model
End-to-end OAM (E2E OAM) flow is used for the OAM communications
between the ingress PE and the egress PE of a logic MS-PW. Segment
OAM (SEG OAM) flow is used for the OAM communications between the
ingress PE and the egress PE of a physical per-segment SS-PW. Refer
to the above reference model, we can deduce the following MS-PW OAM
reference model.
+----+ +-----+ +-----+ +----+
+----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+
| |-----|..................E2E OAM...................|-----| |
| CE1| | | | | | | | | |CE2 |
| |-----|----SEG OAM-------SEG OAM-------SEG OAM-----|-----| |
+----+ | |======| |=======| |=======| | +----+
+----+ +-----+ +-----+ +----+
Figure 3 MS-PW OAM layer reference model
3. MS-PW OAM functions
3.1. Segment OAM and End-to-end OAM
End-to-end OAM (E2E OAM) packets are generated at U-PE of a MS-PW,
transferred transparently across all S-PEs, and terminated at the
remote end U-PE of the MS-PW. Segment OAM (SEG OAM) packets are
generated at U-PE of a SS-PW, terminated at the remote end U-PE of
the SS-PW, where U-PE can be U-PE of the SS-PW, or S-PE of the MS-PW.
SEG OAM mechanism is as same as the existing OAM mechanism defined in
[VCCV], [OAMMAP], [CTRL].
For each SS-PW, SEG OAM mechanisms could be adopted. For each MS-PW,
E2E OAM mechanisms could be used as described in following.
For example, when we use one MS-PW to protect another MS-PW, we can
use the E2E OAM mechanisms. If only one segment of the MS-PW, for
some reasons such as management/resource/environment conditions, need
be protected, SEG OAM must only be used at some specific PW segment.
Dong Expires April 10, 2006 [Page 4]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
Of course, we maybe perform E2E OAM and SEG OAM mechanisms over a MS-
PW and its segment PWs at the same time.
When S-PE receives one OAM packet, it must determine whether it is a
SEG OAM packet or an E2E OAM packet. The existing OAM mechanism can't
perform this, so it must be enhanced.
The ingress PE or the egress PE that belongs to one SS-PW shall
discard all the segment OAM packets coming from another PW segment.
3.2. Fault Notification
A PE can receive all kinds of faults reported. The PE may receive
physical layer fault report, such as loss of signal. The PE itself
may also detect segment fault by VCCV mechanism. An S-PE is also a PE.
When an S-PE receives fault report from server layer or a segment
fault is detected, the S-PE must forward the fault information to the
remote end U-PE of the MS-PW. When a U-PE receives such fault
information, it can suppress other alarm information or trigger
protection switching. This mechanism is called FDI (Forwarding Defect
Indication).
At the S-PE, defects in a PSN tunnel must be propagated to all PWs
that utilize the tunnel. And FDI OAM packets should be sent to all
these PWs.
The S-PE which detects a fault shall generate and send out FDI
packets to all effected active PWs in the forwarding direction. These
faults include, without limit to:
- transport tunnel faults;
- faults coming from PW status notification;
- faults detected by local OAM mechanisms, such as BFD;
- local PE faults, such as control software faults.
The FDI packets shall be generated and sent to the downstream U-PE of
the MS-PW from S-PE as soon as possible when any fault is detected.
The FDI packets shall be sent periodically until the fault is
recovered. The transmission speed should be one packet per second.
The egress PE of a MS-PW will maintain the status of FDI for each MS-
PW. When the egress PE receives a valid FDI packet, the corresponding
MS-PW will enter into the FDI state. If the egress PE received E2E
OAM packets from the ingress PE, or no FDI packets are received in
Dong Expires April 10, 2006 [Page 5]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
the three consecutive transmission periods (e.g., three seconds), the
MS-PW will exit FDI state.
When the U-PE of a MS-PW received a FDI packet, it will send PW
status TLV to the peer side U-PE of the MS-PW to notify the current
MS-PW status.
When an S-PE detected a fault, if the S-PE supports segment OAM
functions, it will send PW status TLV to the peer side U-PE of the
SS-PW to notify the current SS-PW status.
To notify fault information to the remote side PE, the following new
OAM packet format is proposed.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fault Type | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
| ,, |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 proposed FDI packet format
Fault Type (16 bits):
Indicates the detected fault type. The fault types and their
encoding are for further study.
Address Family (16 bits):
Indicates the family of the latter address field. Currently
there are two types of address family: IPv4 and IPv6.
Address Family Address Encoding
IPv4 4 octet full IPv4 address
IPv6 16 octet full IPv6 address
Address (16 octets):
Indicates the location information of the PE that generates the
FDI packet. Its value is the IP address of this PE. When the
Dong Expires April 10, 2006 [Page 6]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
address family is IPv4, the first 12 octets of this field are
filled with zero.
Lifetime (32 bits):
Indicates the transmission period of FDI packets to the
receiver. Its unit is millisecond.
3.3. OAM Extension
There are three kinds of OAM data channel [VCCV], which are inband
VCCV, out-of-band VCCV, and TTL expiry VCCV. The first one uses the
first four nibbles 0001 of the control word to identify OAM packets.
The second one uses router alert label to identify the OAM packets.
The last one uses TTL= 1 to force the PE process the OAM packets.
Because both SEG OAM and E2E OAM have BFD/LSP PING/ICMP PING packet,
the type of segment OAM packet must be distinguished, i.e. , SEG OAM
packet or E2E OAM packet. When a PE receives an OAM packet, it must
determine the packet type (FDI, or others), because FDI checking
procedure is different from procedure of other packet types.
3.3.1. Inband VCCV Extension
The following PW Associated Channel Header format is proposed to
extend the OAM.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1| FmtID |T|F| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 PW Associated Channel Header
The meaning of the fields of above PW Associated Channel Header
(Figure 5) are as follows:
FmtID: refer to [CW].
T:
Indicates the segment type of OAM packet.
T = 0 indicates it is SEG OAM packet.
T = 1 indicates it is E2E OAM packet.
Dong Expires April 10, 2006 [Page 7]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
F:
Indicates the FDI type of OAM packet.
F = 0 indicates it is not a FDI packet.
F = 1 indicates it is a FDI packet.
Reserved: MUST be set 0, and ignored in reception.
Channel Type: Refer to [CW].
3.3.2. Out-of-band VCCV Extension
The out-of-band OAM is generally used when the control word is not
used, or the receiving hardware can't process the control word, in
the out-of-band VCCV channel. The VCCV control channel can be created
via using the MPLS router alert label [RFC3032].
The indicator flag in the payload header may be added to identify the
type of OAM packet as the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|F| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM payload |
| ,, |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 OAM payload format
The meaning and value of T and F fields are as same as that in inband
VCCV.
3.3.3. Expiry TTL VCCV Extension
For expiry TTL VCCV, it is possible that using control word or not
using control word. The OAM payload format described in section 3.3.2
is proposed.
Dong Expires April 10, 2006 [Page 8]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
4. OAM Capability Indication for Multi-segment PW using MPLS
4.1. Introduction
For a MPLS-PSN, the PE negotiates the utilization of the VCCV when
the label mapping messages are exchanged to establish the PW. A new
OAM TLV is signaled as part of the PW FEC interface parameters TLV
[VCCV].If LDP PW ID FEC (FEC 128) is used, the OAM capability TLV is
carried in the Interface Parameter's field. If the LDP Generalized PW
ID FEC (FEC 129) is used, it is carried as a sub-TLV in the Interface
Parameter's TLV.
The CV Type Indicator's field in this TLV defines a bit-mask used to
indicate the specific OAM capabilities that the PE can make use of
over the PW being established.
The defined values are:
0x01 ICMP Ping (predefined in [VCCV])
0x02 LSP Ping (predefined in [VCCV])
0x04 BFD for PW Fault Detection only (predefined in [VCCV])
0x08 BFD for PW Fault Detection and AC/PW Fault
Status Signaling (predefined in [VCCV])
0x10 FDI
0x20 SEG OAM
0x40 E2E OAM
A CV type of 0x08 is part of the MS-PW OAM capabilities. It indicates
that the PE supports FDI function. When S-PE detects the fault, it
will notify the remote side PE of the fault and the latter enters
into the proper PW defect state and triggers the appropriate actions.
A CV type of 0x10 is part of the MS-PW OAM capabilities. It indicates
that the PE supports segment OAM function. In general, PE will
support segment OAM function, this CV type provides an option to open
or close the function. It benefits in saving the OAM bandwidth.
A CV type of 0x20 is part of the MS-PW OAM capabilities. It indicates
that the PE supports end-to-end OAM function. When S-PE receives a
E2E OAM packet, it will forward the packet transparently.
Dong Expires April 10, 2006 [Page 9]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
Note that FDI packet must be E2E OAM packet.
After the negotiation process of OAM capability, U-PE may adopt SEG
OAM, or E2E OAM, or both of them. When U-PE adopted both, it must
send the two types of OAM packet at the same time. S-PE only
generates the SEG OAM packets and the FDI packets, forwards the E2E
OAM packets including the FDI packets, and terminates the received
SEG OAM packets. If S-PE doesn't adopt SEG OAM, it should drop the
received SEG OAM packet and doesn't generate any SEG OAM packets. If
S-PE does not adopt E2E OAM, it should drop the received E2E OAM
packet. This case is for further study if S-PE should generate the
FDI packets.
5. MS-PW OAM procedures in IP PSN
When L2TPv3 is used to setup a PW over an IP PSN, [VCCV] uses L2-
Specific sublayer to carry VCCV messages, and describes an L2TPv3
VCCV capability AVP which provides the equivalent means to signal OAM
capabilities between PEs for PW over a L2TP-IP PSN.
To support FDI function of the MS-PW OAM capability, a new type of
FDI AVP message is defined. To support the new MS-PW OAM capability
indicators, a new CV type in VCCV Capability AVP message is defined.
5.1. L2TPv3 VCCV FDI AVP Message
The VCCV message MUST contain a VCCV AVP. It does not contain a
message header. This could either be a new VCCV ICMP Ping AVP or VCCV
BFD AVP or VCCV FDI AVP. The former two are described in [CTRL].
The VCCV FDI AVP encodes the FDI Packet. This AVP may be followed by
the L2TPv3 Remote End Identifier AVP to identify the PW associated
with the session.
5.2. L2TPv3 VCCV Capability Indication AVP Message
A LCCE or a LAC should be able to indicate whether the session is
capable of processing VCCV packets by including the optional VCCV
capability AVP in an ICRQ, ICRP, OCRQ or OCRP.
The CV Type Indicators field in this AVP message defines a bitmask
used to indicate the specific type or types (i.e.: none, one or more)
of IP control packets that may be sent on the specified control
channel. The defined values are:
0x01 ICMP Ping (predefined in [VCCV])
Dong Expires April 10, 2006 [Page 10]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
0x02 BFD (predefined in [VCCV])
0x04 FDI
0x08 SEG OAM
0x10 E2E OAM
The meaning of the CV type is as same as described in section 4.1.
The OAM procedure after negotiation of OAM capability is as same as
described in section 4.1.
6. Security Considerations
This draft does not have any additional impact on security of PWs in
[VCCV].
7. Acknowledgments
The authors would like to thank Spencer Dawkins, Yuli Shi for their
valuable comments and suggestions.
8. References
8.1. Normative References
[VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit
Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-
07.txt, August 2005.
[CTRL] Luca Martini (ED), Toby Smith, "Pseudowire Setup and
Maintenance using the Label Distribution Protocol", draft-
ietf-pwe3-control-protocol-17.txt, June 2005.
[OAMMAP] Thomas D. Nadeau, Peter Busschbach, Mustapha Aissaoui,
"Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3-
oam-msg-map-02.txt, February 2005.
[MSPWREQ] Luca Martini, Matthew Bocci, Nabil Bitar, "Requirements for
inter domain Pseudo-Wires", draft-martini-pwe3-mh-pw-
requirements-01.txt, February 2005.
[CW] S. Bryant, G. Swallow, D. McPherson, "PWE3 Control Word for
use over an MPLS PSN", draft-ietf-pwe3-cw-05.txt, July 2005.
Dong Expires April 10, 2006 [Page 11]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC3031, January 2001.
[RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D.,
Fedorkow,G., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC3032, January 2001.
8.2. Informative References
[ARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,March
2005.
[REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo
Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September
2004.
9. Author's Addresses
Jixiong Dong
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: dongjixiong@huawei.com
10. 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
Dong Expires April 10, 2006 [Page 12]
Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dong Expires April 10, 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 05:52:38 |