Network Working Group Praveen Muley
Internet Draft Mustapha Aissaoui
Intended status: Standards Track Matthew Bocci
Expires: August 2007 Pranjal Kumar Dutta
Marc Lasserre
Alcatel-Lucent
Jonathan Newton
Cable & Wireless
Olen Stokes
Extreme Networks
Hamid Ould-Brahim
Nortel
February 25, 2007
Preferential Forwarding Status bit definition
draft-muley-dutta-pwe3-redundancy-bit-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.
This document may only be posted in an Internet-Draft.
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
Muley et al. Expires August 25, 2007 [Page 1]
Internet-Draft Preferential forwarding bit February 2007
This Internet-Draft will expire on August 25, 2007.
Abstract
This document describes a mechanism for standby status signaling of
redundant PWs between its 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 the 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.....................................................3
3. Signaling procedures of PW State Transition....................4
3.1. PW Standby notification procedures in Master/Slave mode...5
3.1.1. PW State Machine.....................................6
3.2. PW Standby notification procedures in Independent mode....8
4. Applicability..................................................8
5. Security Considerations........................................8
6. IANA Considerations............................................9
6.1. Status Code for PW Preferential Forwarding Status.........9
7. Acknowledgments................................................9
8. References.....................................................9
8.1. Normative References......................................9
8.2. Informative References....................................9
Author's Addresses...............................................10
Intellectual Property Statement..................................11
Disclaimer of Validity...........................................12
Acknowledgment...................................................12
o
Muley et al. Expires August 25, 2007 [Page 2]
Internet-Draft Preferential forwarding bit February 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 the backup PW terminates on a different
target PE node. 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. More details are
provided in [4]. PSN protection mechanisms cannot protect against
failure of the target PE node or the failure of the remote AC.
In multi-segment PW (MS-PW) applications, a primary and multiple
secondary PWs in standby mode 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
Currently the operational status defined in the PWE3 control protocol
[2] introduces two states to AC and PW, Operationally UP or DOWN. The
scenarios defined in [4] require more states to make forwarding
decision of the traffic. This draft defines a new status bit called
preferential forwarding status bit and introduces two additional
states to PW, Active and Standby, to indicate the preferred PW path
to forward traffic to one another.
o Active State
A PW is considered to be in Active state when the PW labels are
exchanged between its two terminating points in control plane and the
corresponding data path is established. In this state data traffic
can flow over the PW in both directions. A PW by default is always in
Active state after it is set UP by signaling.
o Standby State
A PW is considered to be in Standby state when the PW labels are
exchanged between its two terminating points in the control plane but
Muley et al. Expires August 25, 2007 [Page 3]
Internet-Draft Preferential forwarding bit February 2007
the data traffic is blocked at either or both the ends. In this state
the blocked end(s) of the PW SHOULD NOT forward data traffic over the
PW but MUST allow PW OAM packets (e.g, VCCV) to be sent and received.
How a PW should be blocked only for data traffic is implementation
specific and is out of scope of this document. In the context of this
document "blocking" a PW means blocking data traffic only and
"unblocking" as vice versa unless specified otherwise.
The preferential forwarding status of active or standby for each PW
in the redundancy set determines the selection of the PW a PE/T-PE
forwards traffic to. There are two modes of operation for the PW
redundancy:
1. Synchronization of PW paths not mandatory (Independent Mode):
PW endpoint nodes advertise independently their Active/Standby states
and each compares local and remote status and select the PW which is
operationally UP and shows both local Active and remote Active in
preference to the other combination of states. If such PW is not
found, then a PE/T-PE MAY forward over a PW which is Active locally
and Standby remotely. No error condition is generated and thus
asymmetric PW path forwarding is allowed.
2. Synchronization of PW paths mandatory (Master/Slave Mode):
A Master/Slave operation is required between the endpoint nodes of
the PWs. There is a single PE/T-PE Master node and one or many PE/T-
PE Slave nodes. The assignment of Master/Slave roles to the nodes is
performed by local configuration.
The Master node ignores the Active/Standby status bits received from
the Slave nodes. The Slave nodes are required to act on the status
bits received from the Master node. When the received status bit
transitions from Active to Standby, a Slave node SHOULD block
forwarding over the PW. If it fails to block it, it does nothing.
When the received status bit transitions from Standby to Active, the
Slave node MUST unblock forwarding over the PW. It fails to block it,
it generates a status bit of "PW not forwarding" back to the Master.
The Master node then unblocks another PW and if successful will reset
the status bit to Standby towards the Slave node that advertised "PW
not forwarding".
3. 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
Muley et al. Expires August 25, 2007 [Page 4]
Internet-Draft Preferential forwarding bit February 2007
forwarding" bit in Status Code that is to be used with PW Status TLV
proposed in [2]. The PW preferential forwarding bit when set is used
to signal Standby state of PW by one terminating point to the other
end. An implementation that uses this mechanism MUST negotiate the
usage of PW status TLV between its T-LDP peers as per [2]. If PW
Status TLV is found to be not supported by either of its endpoint
after status negotiation procedures then the mechanism proposed in
this document SHOULD NOT be used.
3.1. PW Standby notification procedures in Master/Slave mode
The central concept of this mechanism is that whenever the Master PW
termination point "actively" blocks or unblocks the PW at its end, it
explicitly notifies the event to the remote Slave termination point.
The slave point carries out the corresponding action on receiving the
PW state change notification. Presence of the PW Standby bit in PW
Status TLV indicates that the PW at the disposing end is blocked and
kept in Standby state, and the PW SHOULD also be blocked at receiving
end. Clearance of the PW Standby bit in PW Status TLV indicates that
the PW at the disposing end is unblocked and is in Active state, and
the receiving end SHOULD make the PW Active if it is blocked earlier.
If the receiving end (slave node) is successful in carrying out the
required action it SHOULD NOT notify disposing end as its role in
this event is passive. If the receiving end fails to block the PW at
its end it SHOULD NOT notify about its failure as anyway the PW is
blocked at disposing end. If the receiving end fails to unblock the
PW it SHOULD notify it as fatal error to the disposing end. The
status bit proposed for this notification is the "PW not forwarding".
This mode of signaling is necessary to keep the termination points of
a PW synchronized in states with respect to each other.
The 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,
Muley et al. Expires August 25, 2007 [Page 5]
Internet-Draft Preferential forwarding bit February 2007
PW Grouping TLV may be used for wildcard status notification for a
group of PWs.
In MS-PW application, the S-PE nodes relay the PW
status notification containing both the operational and preferential
forwarding status to the T-PE nodes.
3.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
STATE EVENT NEW STATE
ACTIVE PW blocked actively STANDBY
Action: Transmit PW Standby bit set
Receive PW Standby bit set STANDBY
Action: PW blocked
Receive PW Standby bit set ACTIVE
but PW blocking failed
Action : None
Receive PW Standby bit set ACTIVE
Muley et al. Expires August 25, 2007 [Page 6]
Internet-Draft Preferential forwarding bit February 2007
but PW Standby bit not supported
Action: None
Receive PW Standby bit clear ACTIVE
Action: None.
Receive PW Not Forwarding bit set Applicable state
Action: Applicable as per [2] as per [2]
STANDBY PW unblocked actively ACTIVE
Action : Transmit PW Standby
bit clear
Receive PW Standby bit clear ACTIVE
Action: PW unblocked
Receive PW Standby bit clear Applicable state
but PW unblocking failed as per [2]
Action : Transmit PW Not Forwarding
bit.
Receive PW Not Forwarding bit set Applicable state
Action: Applicable procedure as per [2] as per [2]
Muley et al. Expires August 25, 2007 [Page 7]
Internet-Draft Preferential forwarding bit February 2007
Receive PW Standby bit set STANDBY
Action :No action
3.2. PW Standby notification procedures in Independent mode
In this mode of operation, each endpoint of the PW selects
independently which PW to activate based on the specific application.
The endpoints advertise the resulting Active/Standby status over all
PWs in the redundancy set.
Each endpoint compares local and remote status and MUST select the PW
which shows local Active and remote Active in preference to any other
combination of local and remote forwarding states. If multiple PWs
show Active/Active, then the PW to forward traffic to is a local
endpoint decision. Thus, asymmetric forwarding over the PW paths is
allowed in this mode.
If there is no Active/Active PW, then an endpoint MAY forward over a
PW which shows other combination of forwarding states. However, the
receiving end may discard the received packets. No error messages are
sent in this case.
In MS-PW application, the S-PE nodes relay the PW status notification
containing both the operational and preferential forwarding status to
the T-PE nodes.
4. Applicability
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. Application of the mechanism for P2MP and MP2MP PW is
again outside the scope and is a subject of future study.
5. Security Considerations
This document uses the LDP extensions that are needed for protecting
pseudo-wires. It will have the same security properties as in LDP [3]
and the PW control protocol [2].
Muley et al. Expires August 25, 2007 [Page 8]
Internet-Draft Preferential forwarding bit February 2007
6. IANA Considerations
We have defined the following codes for the pseudo-wire redundancy
application.
6.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".
7. 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.
8. References
8.1. Normative 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] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.
Thomas, "LDP Specification", RFC 3036, January 2001
8.2. Informative References
[4] Praveen, Pranjal et al., "draft-muley-pwe3-redundancy-01.txt" ,
August 2007.
Muley et al. Expires August 25, 2007 [Page 9]
Internet-Draft Preferential forwarding bit February 2007
Author's Addresses
Praveen Muley
Alcatel-Lucent
701 E. Middlefiled Road
Mountain View, CA, USA
Email: Praveen.muley@alcatel-lucent.com
Mustapha Aissaoui
Alcatel-Lucent
600 March Rd
Kanata, ON, Canada K2K 2E6
Email: mustapha.aissaoui@alcatel-lucent.com
Muley et al. Expires August 25, 2007 [Page 10]
Internet-Draft Preferential forwarding bit February 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
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
Muley et al. Expires August 25, 2007 [Page 11]
Internet-Draft Preferential forwarding bit February 2007
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, 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Muley et al. Expires August 25, 2007 [Page 12]