One document matched: draft-martini-pwe3-static-pw-status-00.txt
Network Working Group Luca Martini
Internet Draft George Swallow
Expiration Date: January 2010 Cisco
Intended status: Standards Track
Matthew Bocci
Alcatel-Lucent
July, 3 2009
Pseudowire Status for Static Pseudowires
draft-martini-pwe3-static-pw-status-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 2010
Abstract
This document specifies a mechanism to signal Pseudowire (PW) status
messages using an PW associated channel (ACh). Such a mechanism is
suitable for use where no PW dynamic control plane exits, known as
static PWs, or where a Terminating Provider Edge (T-PE) needs to send
a PW status message directly to a far end T-PE. The mechanism allows
PW OAM message mapping and PW redundancy to operate on static PWs.
Martini, et al. [Page 1]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
Table of Contents
1 Specification of Requirements ........................ 2
2 Introduction ......................................... 2
3 Terminology .......................................... 3
4 Applicability ........................................ 3
5 Pseudowire Status Operation .......................... 3
5.1 PW OAM Message ....................................... 3
5.2 Sending a PW Status Message .......................... 5
5.3 PW OAM status message transmit and receive ........... 5
5.3.1 Acknowledge of PW status ............................. 6
5.3.2 Applicable PW status Bits ............................ 6
5.4 MPLS Label Stack ..................................... 7
5.4.1 Label stack for a message destined to the next PE .... 7
5.4.2 Label stack for a message destined to the egress PE .. 7
6 S-PE operation ....................................... 8
6.1 Static PW to another Static PW ....................... 8
6.2 Dynamic PW to Static PW or vice verso ................ 8
7 Security Considerations .............................. 8
8 IANA Considerations .................................. 8
9 References ........................................... 9
9.1 Normative References ................................. 9
9.2 Informative References ............................... 9
10 Author's Addresses ................................... 9
1. Specification of Requirements
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 [RFC2119].
2. Introduction
The default control plane for Pseudowire (PW) technology, as defined
in [RFC4447], is based on LDP. However that document also describes a
static provisioning mode without control plane. When a static PW is
used , there is no method to transmit the status of the PW, or
attachment circuit (AC) between the two PEs at each end of the PW.
This document defines a method to transport the PW status codes
defined in [RFC4447], sec 5.4.2, and [REDUNDANCY] in-band with the PW
data using a generic associated channel [RFC5586].
Martini, et al. [Page 2]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
3. Terminology
FEC: Forwarding Equivalence Class
LDP: Label Distribution Protocol
LSP: Label Switching Path
MS-PW: Multi-Segment Pseudowire
PE: Provider Edge
PW: Pseudowire
SS-PW: Single-Segment Pseudowire
S-PE: Switching Provider Edge Node of MS-PW
T-PE: Terminating Provider Edge Node of MS-PW
4. Applicability
The procedures described in this draft are intended for the case
where PWs are statically configured. Where an LDP control plane
exists, this MUST be used for signaling all PW status messages with
the exception of those specified in [REDUNDANCY]. For [REDUNDANCY],
the 'S-PE' bypass mode described below MAY be used in the presence of
an LDP control plane.
5. Pseudowire Status Operation
5.1. PW OAM Message
The PW status TLV as defined in [RFC4447] sec 5.4.2 is transported in
a PW OAM message using the PW associated channel (ACH).
Martini, et al. [Page 3]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
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|Version| Reserved | 0xZZ PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Length | Refresh Timer |A| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH PW OAM Message Packet Header.
The first nibble (0001b) indicates the ACH instead of PW data. The
version and the reserved values are both set to 0 as specified in
[RFC4385].
The ACH TLV header is defined in [RFC5586] section 3.2, and contains
the length of ACH TLVs. In this application the long word is set to 0
as there are no ACH TLVs.
Th length field indicates the length of all PW OAM TLVs only.
The refresh timer is specified in seconds with a range from 1 to 255.
The value 0 means that the refresh timer is set indefinitely, and the
PW OAM message will never be refreshed, and will never timeout. This
mode SHOULD NOT be used other then when specified in this document.
The A flag bit is used to indicate an acknowledgment of the PW status
TLV included. The rest of the flag bits are reserved and they must be
set to 0 on transmit, and ignored upon receive. When the A bit is set
, the refresh timer value is a requested timer value. PW OAM Message
code point = 0xZZ. [ZZ to be assigned by IANA from the PW Associated
Channel Type registry.]
TLV types for use in this message are allocated by IANA in the LDP
registry named: "TLV TYPE NAME SPACE" .
Martini, et al. [Page 4]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
5.2. Sending a PW Status Message
PW Status messages are indicated by sending in-band PW OAM messages
for a particular PW containing the PW status TLV defined in
[RFC4447]. The PW TLV format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PW Status Message Format.
The first 2 bits are reserved , and MUST be set to zero on transmit ,
and ignored on receive.
The PW status TLV is prepended with an PW OAM message header and sent
on the ACH of the PW to which the status update applies.
To clear a particular status indication, the PE needs to send a new
PW OAM message containing a PW Status TLV with the corresponding bit
cleared.
The procedures described in [SEGMENTED] that apply to an S-PE and PW
using an LDP control plane also apply when sending PW status using
the PE OAM channel. The OPTIONAL optional procedures using the S-PE
TLV described in [SEGMENTED] can also be applied when sending PW
status using the PE OAM channel.
The detailed message transmit, and receive procedures are specified
in the next section.
5.3. PW OAM status message transmit and receive
Unlike the PW status procedures defined in [RFC4447] with this method
there is no TCP/IP session, or session management. Therefore he PW
OAM message containing the PW status TLV needs to be transmitted
repeatedly to ensure reliable message delivery.
The PW OAM message containing a PW status TLV with a new status bit
set, will be transmitted twice at an initial interval of one second.
Subsequently the PW OAM message will be transmitted with an interval
specified by refresh timer value in the packet. Note that this value
MAY be updated in the new PW OAM message packet, in which case the
Martini, et al. [Page 5]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
new refresh timer value becomes the new packet transmit interval.
When a PW OAM message containing a status TLV is received, a timer is
started according to the refresh rate specified in the packet. If
another non zero PW status message is not received within 3.5 times
specified timer value, the status condition will timeout in 3.5 times
the last refresh timer value received, and the default status of zero
is assumed on the PW.
To clear a particular status fault the PE need only send an updated
message with the corresponding bit cleared. If the PW status word is
zero, the PW OAM message will be sent with the method described above
, however it MUST be acknowledged with a packet with a timer value of
zero. This will cause the PE sending the message to stop sending, and
continue normal operation.
5.3.1. Acknowledge of PW status
The PE receiving a PW OAM message containing a PW status message can
acknowledge the PW status message by simply building an almost
identical reply packet with the A bit set, and transmitting it on the
PW ACH back to the source of the PW status message. The timer value
set in the reply packet will then be used as the new transmit
interval. If the sender PE of a PW status message receives an
acknowledge for a particular message where the PW status TLV matches
exactly the PW status TLV in the message that is currently being
refreshed, the sender PE MUST use the new timer value received.
If the sender PE receives an acknowledge message that does not match
the current active PW status message being sent, it simply ignores
the acknowledgment packet.
If a PE that has a non zero status word for a particular PW, detect
by any means that the peer PW has become unreachable, it will follow
the standard procedures and consider that PW as having an additional
status bit set. This would, normally trigger sending updates again,
and canceling the acknowledge refresh timer state.
5.3.2. Applicable PW status Bits
In some situations it might not be useful or possible to transit a PW
status message because the remote PE is not reachable. For example a
PE that detects a local PSN TX fault condition , will be unable to
transmit a PW OAM message with a PW status TLV reflecting that
condition. The general rule is that a PE or S-PE should always
attempt to send a PW status message.
Martini, et al. [Page 6]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
5.4. MPLS Label Stack
With one exception , all PW OAM status messages are are sent to the
adjacent PE across the PSN tunnel. in many cases the transmitting PE
has no way to determine whether the adjacent PE is a S-PE , or a T-
PE. This is a necessary behavior to preserve backward compatibility
with PEs that do not understand MS-PWs. In the procedures described
in this document there are two possible destinations for the PW OAM
status messages: the adjacent PE, or the T-PE. Sending a PW status
message directly to the T-PE is a enhanced method that is only
applicable using PW OAM status messages sent in the PW ACH.
5.4.1. Label stack for a message destined to the next PE
A PE that needs to forward a PW OAM status message to the adjacent PE
across the PSN tunnel, MUST set the PW label TTL field to 1.
Furthermore if the control word is not in use on the particular PW ,
the PE MUST also place the GAL reserved label [RFC5586], below the PW
label also with the TTL field set to 1.
5.4.2. Label stack for a message destined to the egress PE
This is known as 'S-PE bypass mode'. A T-PE that requires sending a
PW OAM status message directly to the corresponding T-PE at the other
end of the PW MUST set the TTL of the PW label to a value that is
sufficient to reach the corresponding T-PE. This value will be
greater then one, but will be set according to the local policy on
the transmitting T-PE. Furthermore if the control word is not in use
on the particular PW , the PE MUST also place the GAL reserved label
[RFC5586], below the PW label with the TTL field set to 1.
It should be noted that this S-PE bypass procedure MUST NOT be used
for the following PW status codes:
0x00000001 - Pseudowire Not Forwarding
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
When a PW status message is sent using this method, the corresponding
PW status message to clear the fault MUST also be sent using this
method.
Martini, et al. [Page 7]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
6. S-PE operation
The S-PE will operate according to the procedures defined in
[SEGMENTED]. The following additional procedures apply to the case
where a static PW segment is switched to a dynamic PW segment that
uses LDP, and the case a static PW segment is switched to another
static PW segment.
6.1. Static PW to another Static PW
The procedures that are described in [SEGMENTED] section 10 also
apply to the case of a static PW switched to another static PW. The
LDP header is simply replaced by the PE OAM header, otherwise the
packet format will be identical. The information that is necessary to
form a SP-PE TLV MUST be configured in the S-PE, or no S-PE TLV will
be sent.
6.2. Dynamic PW to Static PW or vice verso
The procedures that are described in [SEGMENTED] section 10 also
apply to this situation. However if the PW label of the LDP
controlled PW segment is withdrawn, by the adjacent PE, the S-PE will
set the PW status code "0x00000001 - Pseudowire Not Forwarding" to
the adjacent PW on the static PW segment.
The S-PE will only withdraw it label for the dynamic, ldp controlled,
PW segment if the S-PE is un-provisioned.
7. Security Considerations
The security measures described in [RFC4447] and [SEGMENTED] are
adequate for the proposed mechanism.
8. IANA Considerations
This document uses a new Associated Channel Type. IANA already
maintains a registry of name "Pseudowire Associated Channel Types". A
value of 0x0022 is suggested for assignment with TLVs. The
description is "PW OAM Message".
Martini, et al. [Page 8]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
9. References
9.1. Normative References
[RFC2119] Bradner. S, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, March, 1997.
[RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
et al., rfc4447 April 2006.
[SEGMENTED] Martini et.al. "Segmented Pseudo Wire",
draft-ietf-pwe3-segmented-pw-12.txt, IETF Work in Progress,
June 2009
[RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN", S. Bryant, et al.,
RFC4385, February 2006.
[REDUNDANCY] Muley et.al. "Preferential Forwarding Status
bit definition", draft-ietf-pwe3-redundancy-bit-01.txt,
IETF Work in Progress, September 2008
9.2. Informative References
[RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.,
"MPLS Generic Associated Channel", rfc5586, June 2009
10. Author's Addresses
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
e-mail: swallow@cisco.com
Martini, et al. [Page 9]
Internet Draft draft-martini-pwe3-static-pw-status-00.txt July 2009
Matthew Bocci
Alcatel-Lucent
Grove House, Waltham Road Rd
White Waltham, Berks, UK. SL6 3TN
e-mail: matthew.bocci@alcatel-lucent.co.uk
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Expiration Date: January 2010
Martini, et al. [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-20 15:03:37 |