PWE3 Working Group Jixiong Dong
Internet Draft Yang Yang
Huawei
Expires: August 2006 February 24, 2006
Operation and Maintenance for Multi-segment Pseudo Wire
draft-dong-pwe3-mspw-oam-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/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 August 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). 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 August 24, 2006 [Page 1]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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
1.1. Terminology.............................................3
2. Reference Model for MS-PW OAM................................3
3. MS-PW OAM functions..........................................5
3.1. Segment OAM and End-to-end OAM..........................5
3.2. Forwarding Defect Indication............................6
3.3. Remote Defect Indication................................8
3.4. Misbranching Detection..................................8
3.5. OAM Extension..........................................11
3.5.1. Inband VCCV Extension.............................11
3.5.2. Out-of-band VCCV Extension........................12
3.5.3. Expiry TTL VCCV Extension.........................12
4. OAM Capability Indication for Multi-segment PW using MPLS...13
4.1. Introduction...........................................13
5. MS-PW OAM procedures in IP PSN..............................14
5.1. L2TPv3 VCCV FDI AVP Message............................14
5.2. L2TPv3 VCCV Capability Indication AVP Message..........14
6. IANA Considerations.........................................15
6.1. VCCV Parameter ID......................................15
6.1.1. CV Types..........................................15
6.2. L2TPv3 Assignments.....................................15
6.2.1. CV Types..........................................15
7. Security Considerations.....................................15
8. Acknowledgments.............................................15
9. References..................................................15
9.1. Normative References...................................15
9.2. Informative References.................................16
10. Author's Addresses.........................................17
11. Intellectual Property Statement............................17
Disclaimer of Validity.........................................18
Copyright Statement............................................18
Acknowledgment.................................................18
1. Introduction
One pseudo-wire may transit 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
Dong Expires August 24, 2006 [Page 2]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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 only one PWE3 network. OAM
mechanisms for MS-PWs MUST provide at least the same capabilities
as those for 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].
In this draft, we introduce some MS-PW OAM mechanisms in details,
including FDI, RDI, SEG/E2E OAM, PW misbranching detection. These
functions are all very useful and can't be supported in [VCCV]. So
it's very necessary to develop the new MS-PW OAM draft.
This draft extends the VCCV mechanism described in [VCCV] to
implement MS-PW OAM functions. It also define fault notifications
such as FDI(Forwarding Defect Indication) and AIS(Alarm Indication
Signal).
1.1. Terminology
The terminology specified in [MSPW-ARCH] and [L2VPN-OAMFRM] applies.
In addition, we define the following terms:
o E2E OAM(end-to-end OAM): the OAM mechanisms apply between the two
T-PEs. S-PE MUST transfer the E2E OAM packets transparently.
o SEG OAM(Segment OAM): the OAM mechanisms apply on PW segment. All
of the PW segment, which is set up between T-PE and S-PE, S-PE and
S-PE, can use the SEG OAM mechanisms. The SEG OAM packets MUST be
terminated at the end of the PW segment, i.e., S-PE or T-PE.
2. Reference Model for MS-PW OAM
The figure below describes PW switching reference model [MSPWREQ].
There are four PW segments in the figure, that is, PW1, PW2, PW3 and
PW4.
Dong Expires August 24, 2006 [Page 3]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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 PW segments, e.g., MS-PW1 contains
two PW segments, PW1 and PW3. One MS-PW can be regarded as one
logical pseudo wire. Each PW segment can be regarded as one
individual physical link. From layer network point of view, MS-PW is
a client sublayer and PW segment is the server sublayer. Thus, the
reference model above can be illustrated by the following figure.
+----+ +-----+ +-----+ +----+
+----+ | 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 T-PE and the egress T-PE of a logical MS-PW.
Segment OAM (SEG OAM) flow is used for the OAM communications between
the ingress PE and the egress PE of a physical PW segment. SS-PW MUST
be regarded as one type of special PW segment. Therefore SS-PW should
use SEG OAM mechanisms. Refer to the above reference model, we can
deduce the following MS-PW OAM reference model.
Dong Expires August 24, 2006 [Page 4]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
+----+ +-----+ +-----+ +----+
+----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+
| |-----| +................E2E OAM.................+ |-----| |
| CE1| | | | | | | | | |CE2 |
| |-----| +---SEG OAM-+ +---SEG OAM-+ +---SEG OAM--+ |-----| |
+----+ | |======| |=======| |=======| | +----+
+----+ +-----+ +-----+ +----+
Figure 3 MS-PW OAM layer reference model
[OAM-APP] introduces the notion of OAM domain, ME, MEP and MIP to the
PWE3 field to build the PWE3 OAM framework. Based on these work, we
can define the MEPs and MIPs in the PW layer of AC/PW/AC layer.
+----+ +-----+ +-----+ +----+
+----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+
| |-----| ..................MS-PW.................. |-----| |
| CE1| | | | | | | | | |CE2 |
| |-----| | | | | | | | | |
+----+ | |======| |=======| |=======| | +----+
+----+ +-----+ +-----+ +----+
C MEP---------MIP-----------MIP-----------MEP
^ ^ ^ ^ ^ ^
| | | | | |
D MEP MEP MEP MEP MEP MEP
C is the MS-PW OAM sublayer
D is the PW segment sublayer
Figure 4 MEPs and MIPs definition for the MS-PW OAM layer
3. MS-PW OAM functions
3.1. Segment OAM and End-to-end OAM
End-to-end OAM (E2E OAM) packets are generated at T-PE of a MS-PW,
transferred transparently across all S-PEs, and terminated at the
peer T-PE of the MS-PW.
Segment OAM (SEG OAM) packets are generated at one end of a PW
segment, terminated at the other end of the PW segment, where the end
of PW segment can be T-PE or S-PE of the MS-PW.
Dong Expires August 24, 2006 [Page 5]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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.
Of course, we maybe perform E2E OAM mechanisms over a MS-PW and SEG
OAM mechanisms over its PW segments 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. If it's SEG OAM packet, it
should be processed by local node. Otherwise, it should be forwarded
transparently. For support the quick OAM process, we should make this
decision by recognizing the OAM packet header. The existing OAM
mechanism can't perform this, so it must be enhanced.
The ingress PE or the egress PE that belongs to one PW segment shall
discard all the segment OAM packets coming from another PW segment.
3.2. Forwarding Defect Indication
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 T-PE of the MS-PW. When a T-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;
Dong Expires August 24, 2006 [Page 6]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
- 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 T-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
the three consecutive transmission periods (e.g., three seconds), the
MS-PW will exit FDI state.
When the T-PE of a MS-PW received a FDI packet, it will send PW
status TLV to the peer side T-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 PE of the PW
segment to notify the current status of the PW segment.
Note that the above backward fault notification mechanism can also
use the specific remote defect indication packet, that is, RDI
mechanism, as the following section.
To notify the 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 5 FDI packet format
Fault Type (16 bits):
Indicates the detected fault type. The fault types and their
encoding are for further study.
Dong Expires August 24, 2006 [Page 7]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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
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. The unit is millisecond.
3.3. Remote Defect Indication
T-PE may use remote defect indication (RDI) to notify the peer T-PE
that a defect has been detected. Loss of Signaling and AIS may result
in transmission RDI.
RDI could be sent in data plane or control plane. It's preferred to
send RDI in data plane if the MS-PW is established in stitching mode.
In dynamic mode, LDP and RSVP-TE signaling could be used to propagate
RDI.
After detecting loss of connectivity/misbranching or receiving FDI
from S-PE or being notified a server layer failure, T-PE will
transmit RDI to the peer T-PE. The fault type may be contained in the
RDI messages.
The packet format of RDI is same as that of the above FDI.
3.4. Misbranching Detection
PW misbranching means one PW segments connects another PW segments
incorrectly. In fact, before introducing multi-segment PW, PW
misbranching has existed. But it's caused by the server layer(s),
such as tunnel LSP, and it's server layer(s). MPLS misbranch
detection mechanisms[xxx itu-t y.1711, 1713] can detect this fault.
Dong Expires August 24, 2006 [Page 8]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
Because it is not caused by PW layer, we don't care it in PWE3 WG.
However, after introducing the multi-segment PW, S-PE has the PW
switching function, which can lead to incorrect switching.
There are two cases of PW misbranching. For example, See figure 6(a),
it's the correct connection case. there are two MS-PWs, MS-PW1
traverses T-PE1, S-PE1, T-PE2, MS-PW2 traverses T-PE3, S-PE2, T-PE4.
Figure 6(b) illustrates one case of PW misbranching. One MS-PW1
segment connects to a MS-PW2 segment at S-PE1 incorrectly, and one
MS-PW2 segment connects to a MS-PW1 segment at S-PE2 incorrectly.
Figure 6(c) illustrates another case of PW misbranching. One MS-PW1
segment connects to MS-PW2 at S-PE1 incorrectly, at the same time one
MS-PW2 segment connects to a MS-PW2 segment at S-PE2 correctly.
T-PE1 S-PE1 T-PE2
o--------o---------o
o--------o---------o
T-PE3 S-PE2 T-PE4
a) correct connection
T-PE1 S-PE1 T-PE2
o--------o o
\ /
\ /
/\
/ \
o--------o o
T-PE3 S-PE2 T-PE4
b) incorrect connection
T-PE1 S-PE1 T-PE2
Dong Expires August 24, 2006 [Page 9]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
o--------o o
\
\
\
\
o--------o--------o
T-PE3 S-PE2 T-PE4
c) incorrect connection
Figure 6 PW misbranching
To detect PW misbranching, we can use the following VCCV oam PDU
packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sourece T-PE id |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PWE3 FEC 128/129 |
| ,, |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | BIP-16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 OAM packet format for PW misbranching
Source T-PE id (16 octets):
Indicates the PW source T-PE address.
PWE3 FEC 128/129 (N bits):
The FEC 128/129 contents when setup the PW. When PW is setup by
using FEC 128, the field fills FEC 128 content. When PW is
setup by using FEC 129, the field fills FEC 129 content.
Dong Expires August 24, 2006 [Page 10]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
reserved (16 bits):
Filled by zero.
BIP-16 (16 bits):
It use the polynomial G(x) = x**16 + 1. The fields before BIP-
16 field is all computed.
The ST-PE send it to the TT-PE. If TT-PE receives the message with
undesired field value(s), it will declare misbranching fault with the
corresponding field mismatching information.
3.5. 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 the procedure of other packet types.
3.5.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 8 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:
Dong Expires August 24, 2006 [Page 11]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
Indicates the segment type of OAM packet.
T = 0 indicates it is SEG OAM packet.
T = 1 indicates it is E2E OAM packet.
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.5.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 9 OAM payload format
The meaning and value of T and F fields are as same as that in inband
VCCV.
3.5.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 August 24, 2006 [Page 12]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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 MS-PW OAM capabilities
A CV type of 0x10 is part of the MS-PW OAM capabilities. It indicates
if the PE supports the new MS-PW OAM capabilities, including
FDI,RDI,SEG,E2E,PW misbranching functions.
After the negotiation process of OAM capability, T-PE may adopt SEG
OAM, or E2E OAM, or both of them. When T-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.
Dong Expires August 24, 2006 [Page 13]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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 [VCCV].
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])
0x02 BFD (predefined in [VCCV])
0x04 MS-PW OAM capabilities
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.
Dong Expires August 24, 2006 [Page 14]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
6. IANA Considerations
6.1. VCCV Parameter ID
VCCV parameter ID codepoint is defined in [PWE3IANA]. IANA is
requested to maintain a registry for the CC Types and CV Types, bit-
masks in the VCCV parameter ID. The allocations must be done using
the "First Come First Served" policy defined in RFC2434. IANA is
requested to reserve the following bits in this registry:
6.1.1. CV Types
0x10 MS-PW OAM capabilities
6.2. L2TPv3 Assignments
L2TPv3 VCCV FDI AVP must also be assigned by IANA. IANA is requested
to maintain a registry for the CV Types, bit-mask in the VCCV
Capability AVP. The allocations must be done using the "First Come
First Served" policy defined in RFC2434. IANA is requested to reserve
the following bits in this registry:
6.2.1. CV Types
0x04 MS-PW OAM capabilities
7. Security Considerations
This draft does not have any additional impact on security of PWs in
[VCCV].
8. Acknowledgments
The authors would like to thank Simon Delord, Spencer Dawkins, Yuli
Shi for their valuable comments and suggestions.
9. References
9.1. Normative References
[MSPW-ARCH] M. Bocci, S.Bryant, " An Architecture for Multi-Segment
Pseudo Wire Emulation Edge-to-Edge ", draft-bocci-bryant-
pwe3-ms-pw-arch-01.txt, October 2005.
[VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit
Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-
07.txt, August 2005.
Dong Expires August 24, 2006 [Page 15]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
[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-ietf-pwe3-ms-pw-
requirements-01.txt, October 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.
[PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for
pseudo Wire Edge to Edge Emulation (PWE3)",
draft-ietf-pwe3-iana-allocation-12.txt, June 2005.
[OAM-APP] Simon Delord, Philippe Niger, Yuichi Ikejiri, Yuichiro
Wada, et al., "PWE3 Applications & OAM Scenarios", draft-
delord-pwe3-oam-applications-01.txt, May 2005.
[L2VPN-OAMFRM] Dinesh Mohan, Ali Sajassi, "L2VPN OAM Requirements
and Framework", draft-ietf-l2vpn-oam-req-frmk-03.txt, July
2005.
9.2. Informative References
[REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo
Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September
2004.
[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.
Dong Expires August 24, 2006 [Page 16]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
10. Author's Addresses
Jixiong Dong
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, P.R.China
Phone: +86-755-28970230
Email: dongjixiong@huawei.com
Yang Yang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, P.R.China
Phone: +86-755-28978567
Email: healthinghearts@huawei.com
11. 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
Dong Expires August 24, 2006 [Page 17]
Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006
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 (2006).
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 August 24, 2006 [Page 18]