One document matched: draft-muley-dutta-pwe3-redundancy-bit-01.txt
Differences from draft-muley-dutta-pwe3-redundancy-bit-00.txt
Network Working Group Praveen Muley
Internet Draft Mustapha Aissaoui
Expires: January 2008 Matthew Bocci
Pranjal Kumar Dutta
Marc Lasserre
Alcatel-Lucent
Jonathan Newton
Cable & Wireless
Olen Stokes
Extreme Networks
Hamid Ould-Brahim
Nortel
Luca Martini
Cisco Systems Inc.
July 6, 2007
Preferential Forwarding Status bit definition
draft-muley-dutta-pwe3-redundancy-bit-01.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.
Muley et al. Expires January 6, 2008 [Page 1]
Internet-Draft Preferential Forwarding Status Bit July 2007
This Internet-Draft will expire on January 6, 2008.
Abstract
This document describes a mechanism for standby status signaling of
redundant PWs between their termination points. A set of redundant
PWs is configured between PE nodes in SS-PW applications, or between
T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to
indicate the preferred PW path to forward to one another, a new
status bit is needed to indicate a preferential forwarding status of
active or standby for each PW in the redundancy set. This draft
specifies a new PW status bit for this purpose.
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].
Table of Contents
1. Introduction...................................................3
2. Motivation.....................................................4
3. Modes of Operation.............................................5
3.1. Independent Mode:.........................................5
3.2. Master/Slave Mode:........................................6
4. Signaling procedures of PW State Transition....................7
4.1. PW Standby notification procedures in Master/Slave mode...7
4.1.1. PW State Machine.....................................8
4.2. PW Standby notification procedures in Independent mode...10
5. Applicability and Backward Compatibility......................11
6. Security Considerations.......................................11
7. IANA Considerations...........................................11
7.1. Status Code for PW Preferential Forwarding Status........11
8. Acknowledgments...............................................12
9. References....................................................12
Author's Addresses...............................................12
Full Copyright Statement.........................................13
Intellectual Property Statement..................................14
Acknowledgment...................................................14
Muley et al. Expires January 6, 2008 [Page 2]
Internet-Draft Preferential Forwarding Status Bit July 2007
1. Introduction
In single-segment PW (SS-PW) services such as VPWS and VPLS,
protection for the PW is provided by the PSN layer. This may be an
RSVP LSP with a FRR backup and/or an end-to-end backup LSP. There are
however applications where PSN protection is insufficient to fully
protect the PWE3 service and pseudowire redundancy is required. These
scenarios are described in [5].
In a VPWS service, this is used to provide access AC redundancy to a
CE device which is dual-homed to target PE nodes. In a HVPLS service,
this is used to provide access PW redundancy to the MTU device which
is dual-homed to two PE-r devices. PSN protection mechanisms cannot
protect against failure of the target PE node or the failure of the
remote AC. These scenarios rely on a set of two or more pseudowires
to protect a given PWE3 service. Only one of these pseudowires is
used by the PEs to forward user traffic on at any given time. This is
the active PW. The other PWs in the set are considered standby and
are not used for forwarding unless they become active.
In order to support access AC or access PW redundancy, at least one
of the PEs on which a PW terminates must be different from that on
which the primary PW terminates, as described in [5]. Figure 1
illustrates an application of Active and Standby PWs.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| | | +-----+
| |----------|....|...PW1.(active)...|....|----------| |
| | | |==================| | | CE2 |
| CE1 | +----+ |PE2 | | |
| | +----+ | | +-----+
| | | |==================| |
| |----------|....|...PW2.(standby)..| |
+-----+ | | PE3|==================| |
AC +----+ +----+
Figure 1: Reference Model for PW Redundancy
Muley et al. Expires January 6, 2008 [Page 3]
Internet-Draft Preferential Forwarding Status Bit July 2007
In multi-segment PW (MS-PW) applications, an active and multiple
standby PWs are configured in the network. The paths of these PWs are
diverse and are switched at different S-PE nodes. In these
applications, PW redundancy is important for the service resilience.
This document specifies a new PW status bit to indicate the
preferential forwarding status of the PW for the purpose of notifying
the remote PE of the active/standby state of each PW in the
redundancy set. This status bit is different from the operational
status bits already defined in the PWE3 control protocol [2].
2. Motivation
The PWE3 control protocol [2] defines the following status codes to
indicate the operational state for an AC and a PW:
0x00000000 - Pseudowire forwarding (clear all failures)
0x00000001 - Pseudowire Not Forwarding
0x00000002 - Local Attachment Circuit (ingress) Receive Fault
0x00000004 - Local Attachment Circuit (egress) Transmit Fault
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
The scenarios defined in [5] allow the provisioning of a primary PW
and one or many secondary PWs in the same VPWS or VPLS service.
A PE node makes a selection of which PW to activate at any given time
for the purpose of forwarding user packets. This selection takes into
account the local operational state of the PW as well as the remote
operational state of the PW as indicated in the status bits of the PW
it received from the peer PE node.
In the absence of faults, all PWs are operationally UP both locally
and remotely and a PE node needs to select a single PW to forward
user packets to. This is referred to as the active PW. All other PWs
will be in standby and must not be used to forward user packets.
In order for both ends of the service to select the same PW for
forwarding user packets, it is proposed that a PE node communicates a
new status bit to indicate the forwarding state of a PW to its peer
PE node.
Muley et al. Expires January 6, 2008 [Page 4]
Internet-Draft Preferential Forwarding Status Bit July 2007
This draft defines a new status bit called the preferential
forwarding status bit and introduces two additional states to PW,
Active and Standby, to indicate the one active PW path to forward
user traffic to and the one or many standby PWs to refrain from
forwarding traffic to.
3. Terminology
UP PW: A PW which has been configured (label mapping exchanged
between PEs) and is not in any of the PW defect states
specified in [2]. Such a PW is available for forwarding
traffic.
DOWN PW: A PW that has either not been fully configured or has been
and is in any of the PW defect states specified in [2].
Such a PW is not available for forwarding traffic.
Active PW: An UP PW used for forwarding user traffic.
Standby PW: An UP PW that is not used for forwarding user traffic.
PW Endpoint: A PE where a PW terminates on an NSP e.g. A SS-PW PE,
and MS-PW T-PE, or a VPLS MTU or PE-r.
4. Modes of Operation
There are two modes of operation for the use of the PW preferential
forwarding status bits:
o Independent mode
o Master/Slave mode.
4.1. Independent Mode:
PW endpoint nodes independently select which PW they intend to make
active and which PWs they intend to make standby. They advertise the
corresponding Active/Standby forwarding state for each PW. Each PW
endpoint compares local and remote status and uses the PW that is
operationally UP at both endpoints and that shows Active states at
both the local and remote endpoint.
In steady state, a PE will always find an Active PW. However, it is
possible that due to a misconfiguration, such a PW is not found. The
behavior of a PE in this case is outside the scope of this document.
Muley et al. Expires January 6, 2008 [Page 5]
Internet-Draft Preferential Forwarding Status Bit July 2007
There may also be transient conditions where endpoints do not share a
common view of the active/standby state of the PWs. This could be
caused by propagation delay of the T-LDP status messages between
endpoints. In this case, the behavior of the receiving endpoint is
outside the scope of this document.
Thus, in this mode of operation, the following definition of Active
and Standby PW states apply:
o Active State
A PW is considered to be in Active state when the PW labels are
exchanged between its two endpoints in control plane, and the status
bits exchanged between the endpoints indicate the PW is UP and Active
at both endpoints. In this state user traffic can flow over the PW in
both directions.
o Standby State
A PW is considered to be in Standby state when the PW labels are
exchanged between its two endpoints in the control plane, but the
status bits exchanged indicate the PW is in Standby state at one or
both endpoints. In this state the endpoints MUST NOT forward data
traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be
sent and received in order to test the liveliness of standby PWs.
4.2. Master/Slave Mode:
One endpoint node of the redundant set of PWs is designated the
Master and is responsible for selecting which PW both endpoints must
use to forward user traffic.
The Master indicates the forwarding state in the Active/Standby
status bit. The other endpoint node, the Slave, MUST follow the
decision of the Master node based on the received status bits.
One endpoint of the PW, the Master, actively selects which PW to
activate and uses it for forwarding user traffic. This status is
indicated to the Slave node by setting the preferential forwarding
status bit in the status bit TLV to Active. It does forward user
traffic to any other of the PW's in the redundant set to the slave
node and indicates this by setting the preferential forwarding status
bit in the status bit TLV to Standby for those PWs. The master node
MUST ignore any Active/Standby status bits received from the Slave
nodes.
Muley et al. Expires January 6, 2008 [Page 6]
Internet-Draft Preferential Forwarding Status Bit July 2007
The Slave endpoint(s) are required to act on the status bits received
from the Master. When the received status bit transitions from Active
to Standby, a Slave node MUST stop forwarding over the previously
active PW. When the received status bit transitions from Standby to
Active for a given PW, the Slave node MUST start forwarding user
traffic over this PW.
There is a single PE/T-PE Master PW endpoint node and one or many
PE/T-PE PW endpoint Slave nodes. The assignment of Master/Slave roles
to the PW endpoints is performed by local configuration.
In this mode of operation, the following definition of Active and
Standby PW states apply:
o Active State
A PW is considered to be in Active state when the PW labels are
exchanged between its two endpoints in control plane, and the status
bits exchanged between the endpoints indicate the PW is UP at both
endpoints, and the forwarding status sent by the Master endpoint
indicates Active state. In this state user traffic can flow over the
PW in both directions.
o Standby State
A PW is considered to be in Standby state when the PW labels are
exchanged between its two endpoints in the control plane, but the
status bits sent by the Master endpoint indicate the PW is in Standby
state. In this state the endpoints MUST NOT forward data traffic over
the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and
received.
5. Signaling procedures of PW State Transition
This section describes the extensions proposed and the processing
rules for the extensions. It defines a new "PW preferential
forwarding" bit in Status Code that is to be used with PW Status TLV
proposed in RFC 4447 [2]. The PW preferential forwarding bit when set
is used to signal Standby state of PW by one terminating point to the
other end.
5.1. PW Standby notification procedures in Master/Slave mode
Whenever the Master PW endpoint "actively" selects or deselects a PW
for forwarding user traffic at its end, it explicitly notifies the
event to the remote Slave endpoint. The slave endpoint carries out
Muley et al. Expires January 6, 2008 [Page 7]
Internet-Draft Preferential Forwarding Status Bit July 2007
the corresponding action on receiving the PW state change
notification.
If the PW preferential forwarding bit in PW Status TLV received by
the slave is set, it indicates that the PW at the Master end is not
used for forwarding and is thus kept in the Standby state, the PW
MUST also not be used for forwarding at Slave endpoint. Clearance of
the PW Preferential Forwarding bit in PW Status TLV indicates that
the PW at the Master endpoint is used for forwarding and is in Active
state, and the receiving Slave endpoint MUST activate the PW if it
was previously not used for forwarding.
This mechanism is RECOMMENDED to be used with PWs signaled in groups
with common group-id in PWid FEC Element or Grouping TLV in
Generalized PWid FEC Element defined in [2]. When PWs are provisioned
with such grouping a termination point sends a single "wildcard"
Notification message using a PW FEC TLV with only the group ID set,
to denote this change in status for all affected PW connections. This
status message contains either the PW FEC TLV with only the Group ID
set, or else it contains the PW Generalized FEC TLV with only the PW
Grouping ID TLV. As mentioned in [2], the Group ID field of the PWid
FEC Element, or the PW Grouping TLV used with the Generalized ID FEC
Element, can be used to send status notification for all arbitrary
set of PWs. For example, Group-ID in PWiD may be used to send
wildcard status notification message for a group of PWs when PWid FEC
element is used for PW state signaling. When Generalized PWiD FEC
Element defined is used in PW state signaling, PW Grouping TLV may be
used for wildcard status notification for a group of PWs.
For MS-PWs, S-PEs MUST relay the PW status notification containing
both the operational and preferential forwarding status bits between
ingress and egress PW segments.
5.1.1. PW State Machine
It is convenient to describe the PW state change behavior in terms of
a state machine. The PW state machine is explained in detail in the
two defined states and the behavior is presented as a state
transition table. The same state machine is seamlessly applicable to
PW Groups.
PW State Transition State Table
Muley et al. Expires January 6, 2008 [Page 8]
Internet-Draft Preferential Forwarding Status Bit July 2007
STATE EVENT NEW STATE
ACTIVE PW put in Standby (master) STANDBY
Action: Transmit PW preferential forwarding bit set
Receive PW preferential forwarding STANDBY
bit set
Action: Stop forwarding over PW
Receive PW preferential forwarding ACTIVE
bit set but bit not supported
Action: None
Receive PW preferential forwarding ACTIVE
bit clear
Action: None.
STANDBY PW activated (master) ACTIVE
Action: Transmit PW preferential forwarding bit
clear
Receive PW preferential forwarding ACTIVE
bit clear
Muley et al. Expires January 6, 2008 [Page 9]
Internet-Draft Preferential Forwarding Status Bit July 2007
Action: Activate PW
Receive PW preferential forwarding STANDBY
bit clear but bit not supported
Action: None
Receive PW preferential forwarding STANDBY
bit set
Action: No action
5.2. PW Standby notification procedures in Independent mode
PW endpoint nodes independently select which PW they intend to use
for forwarding, and which PWs they do not, based on the specific
application. They advertise the corresponding Active/Standby
forwarding state for each PW. This advertisement occurs in both the
initial label mapping message and in a subsequent notification
message when the forwarding state transitions as a result of a state
change in the specific application.
Each endpoint compares the updated local and remote status and
effectively activates the PW which is operationally UP at both
endpoints and which shows both local Active and remote Active states.
When a PW is in active state, the endpoints can forward both user
packets and OAM packets.
When a PW is in standby state, the endpoints MUST NOT forward user
packets over the PW but MAY forward PW OAM packets.
For MS-PWs, S-PEs MUST relay the PW status notification containing
both the operational and preferential forwarding status bits between
ingress and egress PWs.
Muley et al. Expires January 6, 2008 [Page 10]
Internet-Draft Preferential Forwarding Status Bit July 2007
6. Applicability and Backward Compatibility
The mechanism defined in this document is OPTIONAL and is applicable
to PWE3 applications where standby state signaling of PW or PW group
is required.
A PE implementation that uses the mechanisms described in this
document MUST negotiate the use of PW status TLV between its T-LDP
peers as per RFC 4447 [2]. If PW Status TLV is found to be not
supported by either of its endpoint after status negotiation
procedures, then the mechanisms specified in this document cannot be
used.
A PE implementation compliant to RFC 4447 [2], and which does not
support the generation or processing of the active/standby status
bit, will not set this bit in the status bits transmitted to a peer
PE and will not examine it in the received status bits from a peer
PE. The mechanisms specified in this document cannot be used.
7. Security Considerations
This document uses the LDP extensions that are needed for protecting
pseudo-wires. It will have the same security properties as in the
PWE3 control protocol [2].
8. IANA Considerations
We have defined the following codes for the pseudo-wire redundancy
application.
8.1. Status Code for PW Preferential Forwarding Status
The PE/T-PE nodes need to indicate to each other the preferential
forwarding status of active/inactive of the pseudo-wire.
0x00000020 When the bit is set, it represents "PW forwarding
standby".
When the bit is cleared, it represents "PW forwarding
active".
Muley et al. Expires January 6, 2008 [Page 11]
Internet-Draft Preferential Forwarding Status Bit July 2007
9. Acknowledgments
The authors would like to thank Vach Kompella, Kendall Harvey,
Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal
Saha, Florin Balus and Philippe Niger for their valuable comments and
suggestions.
10. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Martini, L., et al., "Pseudowire Setup and Maintenance using
LDP", RFC 4447, April 2006.
[3] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-pwe3-
segmented-pw-05.txt, July 2007.
[4] Bryant, S., et al., " Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture", RFC 3985, March 2005
[5] Praveen, Pranjal et al., "draft-muley-pwe3-redundancy-01.txt",
March 2007.
Author's Addresses
Praveen Muley
Alcatel
701 E. Middlefiled Road
Mountain View, CA, USA
Email: Praveen.muley@alcatel.com
Mustapha Aissaoui
Alcatel
600 March Rd
Kanata, ON, Canada K2K 2E6
Email: mustapha.aissaoui@alcatel.com
Muley et al. Expires January 6, 2008 [Page 12]
Internet-Draft Preferential Forwarding Status Bit July 2007
Matthew Bocci
Alcatel-Lucent
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks, UK SL6 2PJ
Email: matthew.bocci@alcatel-lucent.co.uk
Pranjal Kumar Dutta
Alcatel-Lucent
Email: pdutta@alcatel-lucent.com
Marc Lasserre
Alcatel-Lucent
Email: mlasserre@alcatel-lucent.com
Jonathan Newton
Cable & Wireless
Email: Jonathan.Newton@cwmsg.cwplc.com
Olen Stokes
Extreme Networks
Email: ostokes@extremenetworks.com
Hamid Ould-Brahim
Nortel
Email: hbrahim@nortel.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
Email: lmartini@cisco.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
Muley et al. Expires January 6, 2008 [Page 13]
Internet-Draft Preferential Forwarding Status Bit July 2007
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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.
Muley et al. Expires January 6, 2008 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 09:58:33 |