INTERNET-DRAFT Pranjal Kumar Dutta L2VPN Working Group Marc Lasserre Expires: April 19,2007 John Rigby Prashanth Ishwar Lucent Technologies October 16, 2006 Signaling Standby State of Pseudowire Groups in H-VPLS draft-pdutta-l2vpn-hvpls-standby-00.txt Status of this Memo 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 19,2007. IPR Disclosure Acknowledgement 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. Abstract H-VPLS is an architecture that follows hub-and-spoke connectivity model among VPLS aware devices and is proposed in [VPLS-LDP] for creating scalable VPLS implementations. To protect from failure of the spoke PW or the failure of host PE-rs, MTU-s may be dual homed to two PE-rs devices for a VPLS instance through primary spoke PW and secondary(standby) spoke PW. The respective PE-rs devices(s) are unaware of the primary or secondary status of spoke PWs. So Broadcast, Unlearned unicast and Multicast (BUM) traffic received from full mesh core by a PE-rs is replicated to MTU-s over secondary spoke PW to get dropped at MTU-s. In such scenerios it may be desirable to block the standby spoke PW at PE-rs end with minimal compromise on traffic disruption when MTU-s performs a switchover to secondary spoke PW. This document proposes an extension to PW status TLV defined in [RFC 4447] to signal Standby or Active state of PW by MTU-s to PE-rs in a scalable manner. Dutta, et. al. Expires April 2007 [Page 1] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 1. Conventions 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. 2. Terminology and Acronyms This document uses terminology and acronyms described in [802.1D-REV],[RFC4664],[RFC3036], [RFC4447] and [VPLS-LDP]. 3. Table of Contents 1. Conventions ....... .........................................2 2. Terminology and Acronyms.....................................2 3. Table of Contents............................................2 4. Introduction.................................................2 5. Pseudowire States............................................4 5.1 Blocked State............................................4 5.2 Active State.............................................5 6. Signaling of PW State Transition.............................5 6.1 PW Standby Status Code...................................5 6.2 Standby PW Group Notification Procedures.................6 6.3 Standby PW Group Signaling between MTU-s and PE-rs.......7 6.4 Standby PW Group Signaling between PEs...................8 7. PW State Machine.............................................9 8. Applicability................................................10 9. Security Considerations......................................10 10. IANA Considerations.........................................11 11. Acknowledgements............................................11 12. References..................................................11 12.1 Normative References....................................11 12.2 Informative References..................................11 Authors' Addresses..............................................11 IPR Disclosure Agreement........................................12 Copyright Notice................................................12 Disclaimer......................................................12 4. Introduction H-VPLS is an architecture proposed in [VPLS-LDP] that implements hub-and-spoke model for scalable connectivity among VPLS aware devices. MTU-s is an edge device in a H-VPLS network that is connected to a "host" PE-rs via one spoke. In this document we consider spokes that are PWs and mechanisms proposed in [RFC4447] are used to signal and maintain the spoke PWs. The host PE-rs device is connected to all other remote PE-rs devices(for same VSI) through core PW(s) connected in full mesh. To protect from connection failure of the spoke PW or the failure of the host PE-rs at its other end, the MTU-s may be dual homed to two host PE-rs devices where one is primary and other is secondary(or standby) with respect to a VPLS instance. Dutta, et. al. Expires April 2007 [Page 2] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 Following scenerio is as per dual homed MTU-s operation as described in [VPLS-LDP]. PE1-rs +--------+ | - | PSN +-----+ | / S \ | - - - -| P |- - - - -| \ / |-------- / +-----+ | --- | +-----+ +--------+ CE-1 | P | | \ +-----+ | \ / Primary/Active spoke PW | \ MTU-s / | +--------+ | | | | | -- | | | / \ | | Full Mesh Core | \S / | | | -- | | +--------+ | / \ Secondary/Standby spoke PW | / \ | / \ | CE-2 +-----+ | | P | +--------+ +-----+ PSN | -- | \ +-----+ | / \ | - - - -| P |- - - - - | \S / | -------- +-----+ | -- | +--------+ PE2-rs Figure 1: An example of a dual homed H-VPLS When the primary spoke PW is active, the secondary spoke PW is blocked and is kept in standby mode at MTU-s, i.e MTU-s will neither transmit nor receive any traffic in the corresponding VSI over secondary spoke PW. Providers may provision PE1-rs as primary device for a group(s) of PWs at MTU-s keeping PE2-rs as secondary and vice versa for another group(s). So primary or secondary status of a PE-rs device with respect to MTU-s is a term applicable per VPLS instance or can be attached to a group of VPLS instances. The dual homed MTU-s is the controller of primary or secondary status of a spoke PW Group for a set VPLS instances. PE1-rs and PE2-rs are unaware of the primary or secondary status of spoke PW group(s) at MTU-s. So Broadcast, Unlearned Unicast and Multicast(BUM) traffic received by PE2-rs from the full mesh core is learned and replicated to MTU-s over the secondary spoke PW groups(s), and the traffic gets dropped finally at MTU-s. Dutta, et. al. Expires April 2007 [Page 3] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 Why is this work necessary? It is to note that the spoke PWs traverse a PSN Tunnel through other P(Provider only) devices. VPLS is a Layer-2 VPN service that may be delivered over public infrastructure transporting other non-VPLS services. For example, the network traversed by secondary PW groups may also be used to carry other low priority internet traffic. If the secondary PW groups are blocked at PE2-rs end then those traffic may utilize the bandwidth effectively. In the existing H-VPLS implementation the advantage of keeping PE-rs devices agnostic of dual homing is fast switchover of traffic at MTU-s when MTU-s switches over to secondary PW group which is similar to APS (Automatic Protection Switching) mechanism in SONET (Synchronous Optical Network). We can either conserve bandwidth over the secondary PWs or have fast switchover to secondary PWs. We have received requests from Service Provider to provide options for blocking the secondary PW groups at PE2-rs which is desirable for scenerios when savings in bandwidth and minimizing packet replication at PE2-rs is considered more important than fast switchover time. In order to avoid the unnecessary replication of traffic at PE2-rs, MTU-s may send label withdraw to PE2-rs in order to bring down all the PWs in a secondary PW Group. In that case, when MTU-s switches over to secondary spoke PW group it has to send label mappings to PE2-rs for all member PWs which is not scalable when large number of PWs are switched together. This document proposes a scalable mechanism to block and unblock the standby PWs at both ends yet with minimal traffic disruption on switchover. The document describes the procedures and recommendations for using PW Status TLV defined in [RFC4447] for signaling the states of PWs between MTU-s and PE-rs. There could be other scenerios of H-VPLS dual homing (e.g Four PE-rs devices connected in ring topology etc.) or other non-VPLS applications of PWE3 where the mechanism can be applicable. 5. Pseudowire States The solution defines following two explicit states of a PW between its termination points after the PW is signaled. 1) Active 2) Standby. 5.1 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 traffic can flow over the PW in both directions. A PW by default is always in Active state after it is set up. Dutta, et. al. Expires April 2007 [Page 4] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 5.2 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 the data path is blocked at either or both the ends. In this state the blocked end(s) of the PW SHOULD NOT forward or receive traffic over the PW. How a PW data path should be blocked is implementation specific and is out of scope of this document. One example could be that the NHLFE entry and ILM entries for the PW can be made invalid or blocked in the switching hardware at the terminating point(s) of the PW. 6. Signaling of PW State Transition This section describes the extensions proposed and the processing rules for the extensions. 6.1 PW Standby Status Code This section defines a new "PW Standby" bit in Status Code that is to be used with PW Status TLV proposed in [RFC4447]. The PW Standby 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 support PW Status TLV for signaling status of PW between its two end points. If PW Status TLV is found to be not supported at either end of the PW after status negotiation procedures as per [RFC4447] then the mechanism proposed in this document SHOULD NOT be used. The format of the PW Status TLV proposed in [RFC 4447] is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. PW Status TLV The status code is a 4-octet bit field as specified in the PW IANA Allocations document [IANA]. The length specifies the length of the Status Code field in octets (equal to 4). Current IANA allocations for Status Code are used for various PW fault notifications. The central concept of this mechanism is that whenever a PW termination point "actively" blocks or unblocks the PW at its end, it explicitly notifies the event to the remote termination point. The remote 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 be blocked at receiving Dutta, et. al. Expires April 2007 [Page 5] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 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 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. This mode of signaling is necessary to keep the termination points of a PW synchronized in states with respect to the each other and also facilitates "wildcard" status signaling of a standby PW Group for scalability. 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 [RFC4447]. If PW Grouping is not used then alternative Label Withdraw method of PW status communication as per [RFC4447] can be used for PW Standby status signaling. 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 [RFC4447], 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 which 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. 6.2 Standby PW Group Notification Procedures The exact procedures that SHOULD be followed with PW Standby bit are explained in detail in the following two specific cases with PW Groups. T1 +=========================+ T2 PW Group Figure 3. PW Group between two points Case 1. PW termination point T1 intends to move the PW Group from Active state to Standby state. T1 blocks all the PWs in the group at its end and SHOULD move the PW Group from Active to Standby state. T1 SHOULD send a wildcard notification to T2 for the PW Group with PW Dutta, et. al. Expires April 2007 [Page 6] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 Standby bit set in PW Status TLV. T2 on receiving the PW Standby bit set in the Status Code blocks all the PWs in the PW Group at its end and moves the state of the PW Group from Active to Standby. Whenever T1 intends to make the PW Group Active it unblocks the respective member PWs and SHOULD move state of the group to Active. T1 SHOULD send a wildcard notification to T2 of its action for the group with PW Standby bit clear. On receiving the notification, T2 SHOULD unblock the member PWs in the PW Group and SHOULD move its state from Standby to Active. If T2 fails to unblock the PWs due to some abnormal condition it SHOULD send PW Not Forwarding bit (defined in [RFC4447]) set in Status Code. Failure to unblock a PW on receipt of notification SHOULD be notified back as a failure condition. T1 processes the response as per PW Not Forwarding bit processing rules in [RFC4447]. Case 2. PW termination point T1 intends to move the PW Group from Active state to Standby state. T1 blocks the PW Group at its end and SHOULD send wildcard notification for the group to T2 with PW Standby bit set in PW Status TLV. If T2 does not support PW Standby bit or it fails to block the PW then T2 SHOULD NOT notify T1 on its failure to take the action. Unable to block the PW Group SHOULD NOT be considered as failure as anyway the group is already blocked at the other end. PE2 SHOULD continue to maintain Active state for the PW. Whenever T1 intends to make the PW Group Active it first unblocks the member PWs at its end. T1 SHOULD move the state of PW group from Standby to Active and SHOULD send a wildcard notification to T2 for the group with PW Standby bit clear in PW Status TLV. If T2 does not support PW Standby bit then it takes no action and continues to be in Active state. Otherwise T2 finds that it is already in Active state and takes no action. 6.3. Standby PW Group Signaling between MTU-s and PE-rs This section explains the application of the mechanism for signaling Standby state of a secondary PW Group by dual homed MTU-s to PE2-rs (figure 4). +--------+ +--------+ Primary PW Group | PE1-rs | | |=====================+--------+ | MTU-s | | |=====================+--------+ +--------+ Secondary PW Group | PE2-rs | +--------+ Figure 4. Dual homed MTU-s Dutta, et. al. Expires April 2007 [Page 7] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 In H-VPLS the PW groups SHOULD be signaled with common group-id in PWid FEC Element or Grouping TLV in Generalized PWid FEC Element for a set of VSIs. The primary factor of PW grouping MUST be done at MTU-s according to primary and secondary status of member PWs in the same set of VSIs. Additional grouping MAY done on factors specific to provider requirements and is out of scope of the solution proposed here. One example of further grouping could be done based on all PWs sharing the same PSN tunnel and PW status at MTU-s. After the MTU-s completes setup of PWs in the primary and secondary group, it blocks all PWs belonging to the secondary group at its end and changes the state of the PWs in the group to Standby. MTU-s sends a wildcard Notification Message to PE2-rs for the secondary PW group containing PW Status TLV with PW Standby bit set. On receiving the notification PE2-rs blocks all the member PWs identified by the group and state of PW group changes to Standby. Whenever MTU-s performs a switchover from the primary PW group to secondary PW group it unblocks all the member PWs in the secondary group and moves the status of the PWs from Standby to Active. MTU-s sends a wildcard Notification Message to PE2-rs for the secondary PW group containing PW Status TLV with PW Standby bit cleared. On receiving the notification PE-2rs unblocks all the member PWs identified by the PW group and state of PW group changes from Standby to Active. It is to note that in this mechanism unless there is a failure to unblock PW groups at PE2-rs, always a single wildcard Notification Message is exchanged per PW group. On failure to unblock the PW group PE2-rs may have to send Notifications of the fatal error per PW as PW grouping is unidirectional as per [RFC4447](in this case from MTU-s to PE-rs only). The status notification defined here is similar to Topology Change Notification in RSTP controlled IEEE Ethernet Bridges in [802.1D- REV] but restricted over a single hop. When the mechanism defined in this document is implemented, PE-rs devices are aware of switchovers at MTU-s and could generate MAC Withdraw Messages to trigger MAC flushing within the H-VPLS full mesh. By default, MTU-s devices should still trigger MAC Withdraw messages as currently defined in [VPLS-LDP] to prevent two copies of MAC withdraws to be sent (one by MTU-s and another one by PE-rs). Mechanisms to disable which devices should trigger MAC Withdraw is out of scope. 6.4 Standby PW Group Signaling between PEs There could be scenerios where standby state notifications of PW groups may be required between two PE devices. One example could be dual homing connectivity between PE devices in a ring topology as in figure 3. Such scenerios may arise in inter-domain H-VPLS deployments where RSTP or other mechanisms may be used to maintain loop free connectivity of PW groups. [VPLS-LDP] outlines about Dutta, et. al. Expires April 2007 [Page 8] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 Multi-domain VPLS service without specifying how redundant border PEs per domain per VPLS instance can be supported. For example in Figure 3 PW Group 1 may be blocked at PE1 by RSTP and it is desirable to block the group at PE2. How the PW grouping should be done here is again deployment specific and is out of scope of the solution. +-------+ +-------+ | PE1 |=====================| PE2 |====... +-------+ PW Group 1 +-------+ || || VPLS Domain A || || VPLS Domain B || || || || || || +-------+ +-------+ | PE3 |=====================| PE4 |==... +-------+ PW Group 2 +-------+ Figure 5. Redundancy in Ring Topology 7. PW State Machine It is convenient to describe the PW state change behaviour in terms of a state machine. The PW state machine is explained in detail in the two defined states and the behaviour 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 but PW Standby bit not supported Action: None Receive PW Standby bit clear ACTIVE Action: None. Dutta, et. al. Expires April 2007 [Page 9] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 Receive PW Not Forwarding bit set Applicable state Action : Applicable as per as per [RFC4447] [RFC4447] 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 [RFC4447] Action : Transmit PW Not Forwarding bit. Receive PW Not Forwarding bit set Applicable state Action : Applicable procedure as as per [RFC4447] per [RFC4447] Receive PW Standby bit set STANDBY Action :No action 8. Applicability The mechanism defined in this document is OPTIONAL and is a tradeoff between savings in bandwidth/resources and traffic switchover time on PW state change from Standby to Active. Implementations SHOULD provide facilties to administratively enable or disable this mechanism based on whether the resulting switchover time is acceptable to SLA between a provider and its customers or not. The target environment of the current solution is dual-homed H-VPLS defined in [VPLS-LDP] and is equally applicable to other possible dual-homing scenerios like when BFD, RSTP is used in a ring topology etc. The solution can be applicable to other non-VPLS applications of PWE3 where standby state signaling of PW or PW group is required. Application of the mechanism in Multi-segment PWs defined in [MHOP-PW] is outside the scope at present and is subject of future study. Application of the mechanism for P2MP and MP2MP PW is again outside the scope and is a subject of future study. 9. Security Considerations. - Control plane aspects - LDP security (authentication) methods as described in [RFC3036] SHOULD be applied. This would prevent unauthenticated LDP Notification messages from changing state of PW in a PE-rs or MTU-s. - Data plane aspects - This initial version of memo does not yet anticipate security Dutta, et. al. Expires April 2007 [Page 10] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 issues associated with data plane. If any such issue arises in future we will have to address those in a next revision. 10. IANA Considerations We define the bitmask 0x00000020 for PW Standby bit in Status Code and is subject to IANA approval. 11. Acknowledgements The authors would like to thank Wijnen Bert and Stephan Roullot for their thorough review and valuable feedbacks on this draft version. 12. References 12.1 Normative References [RFC3036] Andersson,L. and et al.,"LDP Specification", RFC 3036, January 2001. [IANA] Martini,L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4447] Martini,L. and et al., "Pseudowire Setup and Maintenance Using Label Distribution Protocol (LDP)", RFC 4447, April 2006. [VPLS-LDP] Lasserre, M. and Kompella,V. , "Virtual Private LAN Services Using LDP", draft-ietf-l2vpn-vpls-ldp-09.txt, work in progress. 12.2 Informative References [RFC4664] L. Andersson et al.,"Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006 [802.1D-REV] IEEE Std. 802.1D-2003-Media Access Control (MAC) Bridges. [MHOP-PW] Martini, L. and et. al., “Dynamic Placement of Multi Segment Pseudo Wires”, draft-ietf-pwe3-dynamic-ms-pw-01.txt, work in progress. Author's Addresses Pranjal Kumar Dutta Lucent Technologies Email: pdutta@lucent.com Marc Lasserre Lucent Technologies Email: mlasserre@lucent.com Dutta, et. al. Expires April 2007 [Page 11] Internet Draft draft-pdutta-l2vpn-hvpls-standby-00.txt October 2006 John Rigby Lucent Technologies Email: rigby@lucent.com Prashanth Ishwar Lucent Technologies Email: pishwar@lucent.com IPR Disclosure Acknowledgement 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. Copyright Notice 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. Disclaimer 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. Dutta, et. al. Expires April 2007 [Page 12]