PWE3 Working Group Haiyan Zhang Internet Draft Eric Li Jixiong Dong Yang Yang Huawei Expires: August 2006 February 17, 2006 Pseudowire Group ID Application draft-zhang-pwe3-gid-app-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. 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 17, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract The Pseudowire Group ID is introduced and simply defined in [PWE3- CTRL], but how to use Pseudowire Group ID has not been definitely expounded. This document details the applications of Pseudowire Group ID. Zhang Expires August 17, 2006 [Page 1] Internet-Draft draft-zhang-pwe3-gid-app-00.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 2. Terminology.................................................3 3. PW Group....................................................3 4. PW Group ID Application......................................3 4.1. PW Group Protection.....................................4 4.1.1. Protection Information.............................6 4.1.2. Monitoring.........................................6 4.1.3. PW Group Setup.....................................7 4.1.3.1. PW Group Setup by Static Provisioning..........7 4.1.3.2. PW Group Setup by Signaling...................8 4.1.4. PW Group Teardown..................................9 4.1.5. PW Group Protection Behavior......................10 5. Security Considerations.....................................10 6. IANA Considerations........................................10 7. Acknowledgments............................................10 8. References.................................................10 8.1. Normative References...................................10 8.2. Informative References.................................11 9. Author's Addresses.........................................11 10. Intellectual Property Statement............................12 Disclaimer of Validity........................................12 Copyright Statement...........................................12 Acknowledgment................................................13 1. Introduction The PW Group ID is introduced in [PWE3-CTRL], and the Group ID field in the PWid FEC element and the PW Grouping ID TLV in the Generalized ID FEC element are defined, i.e. an arbitrary 32 bit value which represents a group of PWs that is used to create groups in the PW space. But the application of PW Group ID has not been definitely expounded. The document describes the further applications of PW Group ID in detail. Zhang Expires August 17, 2006 [Page 2] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 2. Terminology The document defines the following additional terms: - PW Group (PWG). A group of PWs, these PWs have some common characters such as the same PW endpoints, the same PW type or the same QoS requirements etc. A group of PWs must have the same Group ID. - Working PW Group (W-PWG). The PW Group is used to transmit the service traffic. The service traffic is switched over to the protection PW Group when the working PW Group failed. - Protection PW Group (P-PWG). The PW Group is used to protect the working PW Group. The service traffic is transmitted by protection PW Group when the working PW Group failed. - Protection Group. The collection of the Working PW Groups and the protection PW Groups that are used to provide extra reliability for the transport of service traffic signals in the Working PW Groups. - Monitored Pseudo Wire (M-PW). A monitored PW in a PWG, and the attribute and status of the M-PW represents the attribute and status of the PWG. The PW Group protection switching is initiated when detecting the fault of M-PW. 3. PW Group In [PWE3-CTRL], the PW group ID is intended to be used as a port index or a virtual tunnel index. The Group ID field or the PW Grouping ID TLV can be used to send "wild card" label withdrawals or "wild card" status notification messages to remote PEs for all affected sets of PWs. In fact, the PW Groups may be composed of one or more, SS-PW or MS-PW PWs by definite rules, and the PWs in the same PW Group must have the same PW Group ID. The different rules may be adopted for the different application. 4. PW Group ID Application The existing protection mechanism adopts the tunnel protection. But the defects of PWs can not be detected at tunnel. If the protection connection of some PW goes wrong, the protection switching from the working tunnel to the protection tunnel can not prevent the traffic Zhang Expires August 17, 2006 [Page 3] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 loss of this PW. Furthermore, the tunnel protection is not applicable to the MS-PW. The PW protection mechanism described in [PWE3-PROTECT] solves the issue of tunnel protection. But the system must monitor every PW. In case of large numbers of PWs, the switching speed and the QoS will be influenced. Therefore, the PW Group protection is introduced and is implemented by PW Group ID. One or more typical PWs in a PW Group are monitored. Not to monitor the tunnel or every PWs, enhance the switching efficiency and reduce the system burthen. The following sections detail that PW Group ID is used for the End- to-End PW Group protection. The other applications of PW Group ID will be studied in the future. 4.1. PW Group Protection For PW Group protection, a PW Group (PWG) must consist of PWs that have the same PW endpoints. The other characters such as the same PW type, the same QoS requirements and the same path etc, may be added as the partition factors, but not be required. The working PWGs (W-PWGs) and corresponding protection PWGs (P-PWGs), that may have the different Group ID and protection information, are established between two PW endpoints. According to the detection and the preference level, the service traffic is switched between the W- PWGs and the P-PWGs, and the protection and recovery are implemented. There are several types for the PW Group protection, such as 1:1, 1+1 1:N or M:N architecture, revertive or non-revertive switching etc. Zhang Expires August 17, 2006 [Page 4] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 PWG3 ------- ------- ------- | PE5 |--------| PE6 |--------| PE7 | | |--------| |--------| | ------- ------- ------- || || || || || || ------- PWG1 ------- | PE1 |.......................| PE2 | | |.......................| | ------- ------- || || || || || .. || || ||PWG4 || || .. || || || ------- PWG2 ------- | PE3 |-----------------------| PE4 | | |-----------------------| | ------- ------- Figure 1 PW Group Protection The one or multiple W-PWGs may be protected by the relevant one or multiple P-PWGs. In Figure 1, there are three PWGs, PWG1, PWG2 and PWG3 between PE1 and PE2, and the three PWGs compose a protection group. The PWG1 is W-PWG and consists of two SS-PWs. The PWG2 is P- PWG and consists of two MS-PWs that transit two S-PEs, PE3 and PE4 along their path. The PWG3 is P-PWG and consisting of two MS-PWs that transit three S-PEs, PE5, PE6 and PE7 along their path. The PWs in the W-PWGs and P-PWGs are corresponding one-to-one, and the corresponding PWs have the same characters such as PW type and QoS requirements etc. A protection group may be established Group by Group or according to the corresponding PWs together. In [PWE3-CTRL], the Group ID must not be required to match in both directions of a PW, i.e. the PWs are identified only by the PW ID or Generalized ID FEC element. But for PWG protection, the PWs are identified by the Group ID field and PW ID field for PWid FEC, or the PW Grouping ID TLV and Generalized ID FEC element for Generalized PWid FEC. For example, the PWs that have the same PW ID and the different Group ID for PWid FEC are different PWs. Between the two PW endpoints, the normal PWs not adopting PWG protection must have the different Group IDs with the PWGs for protection. Zhang Expires August 17, 2006 [Page 5] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 4.1.1. Protection Information When the fault takes place, the protection information of the PWGs decided the protection behavior. The protection information includes the protection preference level, the protection type and scheme etc. The PWG has the highest preference level is W-PWG. The PWs in the same PWG must have the same protection information. Since the PWs are bidirectional, the protection information need be manually configured or exchanged by signaling between the two PW endpoints to achieve the consistent with each other for a PWG. The Protection TLV defined in [PWE3-PROTECT] can be used to exchange the protection information. But some bits of the TLV must be used to distinguish the PWG protection from the PW protection. The PWs in the same PWG must have the same Protection TLV. Otherwise, a new PWG Protection TLV may be defined to indicate and exchange the PWG protection information. In this case, the PWs in the same PWG may have the same or the different Protection TLV and must have the same PWG Protection TLV. 4.1.2. Monitoring The status of a PWG can be obtained by monitoring one or more typical PWs in the PWG. The monitored PWs (M-PWs) in W-PWGs and P-PWGs may be inconsistent. If the PWs in a PWG have the different path, it is proposed that there is at least one M-PW in every different path. The protection switching and recovery may be originated by the status change or the VCCV messages in M-PWs. PW status signaling messages are used as the default mechanism for AC and PW status and defect notification for MPLS PSN. The Status Codes value allocations in [IANA] are as follows: Bit Mask Description 0x00000000 - Pseudo Wire Forwarding (clear all failures) 0x00000001 - Pseudo Wire Not Forwarding 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 0x00000008 - Local PSN-facing PW (ingress) Receive Fault Zhang Expires August 17, 2006 [Page 6] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 0x00000010 - Local PSN-facing PW (egress) Transmit Fault The above statuses are periodically conveyed by PW status signaling messages in M-PWs between the two PW endpoints. When the status change takes place in either PW endpoint, the status is immediately conveyed. LRF status (0x00000008) may be produced by the PW forwarder receive fault, interface fault of the PW endpoints, or the service layer of the PW. LTF status (0x00000010) may be produced by the PW forwarder transmit fault, interface fault of the PW endpoints, or the service layer of the PW. When the PW endpoints detect or be notified of LRF or LTF status in one or more M-PWs of the W-PWG, and the normal status (0x00000000) in all M-PWs of the P-PWG, the service will be switched from the W-PWG to the P-PWG. The other statuses do not belong to PW status, and can not start the PWG protection switching. Optionally, the PW endpoints can negotiate the use of VCCV for fault detection in M-PW. The VCCV messages are periodically conveyed in M-PWs between the two PW endpoints. When the PW endpoints do not receive VCCV messages in one or more M-PWs of the W-PWG for a defined period of time, and VCCV messages are normally received in all M-PWs of the P-PWG, the service will be switched from the W-PWG to the P-PWG. 4.1.3. PW Group Setup 4.1.3.1. PW Group Setup by Static Provisioning The PWs in a PWG are established with the same Group ID by the existing SS-PW or MS-PW signaling or static configuration. The protection information for the W-PWGs and P-PWGs is manually configured at the two PW endpoints. The particular protection information includes: - Protection Mode, specify PW Protection or PWG Protection. - Protection Type, specify Hot Standby or Warm Standby. Zhang Expires August 17, 2006 [Page 7] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 - Protection Scheme, specify 1:1, 1+1, 1:N or M:N Protection. - Preference Level, specify the PWGs preference level to determine the switching preemption behavior. - Recovery Type, specify revertive or non-revertive. - M-PWs, specify the PWs to be monitored. - W-PWGs and P-PWGs, bind the W-PWGs and the P-PWGs into a sigle protection group by associating the Group IDs of W-PWGs and P-PWGs. 4.1.3.2. PW Group Setup by Signaling The PWG protection can be implemented by Group ID, and need not extend the existing PW control and maintenance signaling. The document details the signaling procedures for 1:1 and 1+1 taking example for Generalized PWid FEC. The signaling procedures for PWid FEC are similar. The signaling procedures for 1:N and M:N will be discussed in the future. In Figure 1, the PE1 sends the Label Mapping messages to initiate the setup of the PWs. The Label Mapping message for the corresponding PWs must have the same PW FEC. The M-PWs are identified by the initial Label Mapping message with a Protection TLV, i.e. only the messages of the M-PWs include the Protection TLV and the messages of the other PWs in the PWG do not include the Protection TLV. Therefore the M-PWs must be first established to confirm the protection attribute of the PWG by the Protection TLV. And the M-PWs in the different PWG must have the different protection preference level. The corresponding PWGs are bound together to a protection group by the M-PWs with the same PW FEC. The PE2 receives the Label Mapping message. If the PE2 does not support the Protection TLV, it will silently ignore the TLV in which the U bit (Unknown message bit) is set and continue the PW setup procedures, i.e. PE2 will send Label Mapping message without the Protection TLV to setup the PW in the opposite direction. But only one PW can be setup per pair of ACs between PE1 and PE2. The PE2 will reply a Label Release message if PE1 send message to setup the extra PWs. Zhang Expires August 17, 2006 [Page 8] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 If the PE2 detects that a Protection TLV is included in the message, the protection mechanism should be implemented. If the protection mode of the Protection TLV indicates the PW protection, the PW protection should be implemented refer to [PWE3-PROTECT]. Otherwise, the protection mode of the Protection TLV indicates the PWG protection and the Group ID is new, then a new PWG is established. The PW is marked as the M-PW and PE2 will send Label Mapping message with the Protection TLV to setup the PW in the opposite direction. In this case, if the PW FEC already exists in the other PWG, then the corresponding PWGs should be bound to a protection group. If the protection mode of the Protection TLV indicates the PWG protection, but the Group ID already exists and the PW FEC is new in the PWG, then the PW will join to the PWG, and the PW is marked as the M-PW. PE2 will send Label Mapping message with the Protection TLV to setup the PW in the opposite direction. If the PW FEC already exists in the PWG, i.e. there exist a PW that has the same Group ID and PW FEC. Then the Label Mapping message is treated as the update message for the PW. This instance is applicable to afresh specify the M-PWs. If the PE2 detects that a Protection TLV is not included in the message and the Group ID is new, the PW has not protection characteristic. PE2 sends the Label Mapping message without the Protection TLV in opposite direction, and a normal PW will be setup. If the PE2 detects that the Group ID already exists and the PW FEC is new in the PWG, then the PW will join to the PWG. PE2 will send Label Mapping message without the Protection TLV to setup the PW in the opposite direction. If the PW FEC already exists in the PWG, i.e. there exist a PW that has the same Group ID and PW FEC. Then the Label Mapping message is treated as the update message for the PW. In the above-mentioned procedures, the preference level in Protection TLV may be specified by the original PE (PE1) or the target PE (PE2). If specified by the target PE, the preference level field may be set to a fixed value in the original message and be set to the usable preference level by target PE in reverse message. 4.1.4. PW Group Teardown Before all M-PWs in a PWG are deleted, the new one or more M-PWs must be established by manually configuration or signaling, or the existing one or more non M-PWs must be afresh specified to the M-PWs by the manually configuration or Label Mapping message with the Protection TLV. Zhang Expires August 17, 2006 [Page 9] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 Otherwise, the fault can not be detected by monitoring the M-PWs, and the protection switching can not be implemented in time, so as to the service is broken off. Once all the M-PWs in a PWG are deleted and no M-PWs exist in the PWG, the PWG may be torn down. Certainly, the PW Group may be torn down by the "wild card" label withdrawal message. 4.1.5. PW Group Protection Behavior When the faults are determined in one or more M-PWs of a W-PWG, and the M-PWs in the P-PWG are normal, the protection switching takes place. After all M-PWs in a W-PWG recovery, it is decided whether the service will revert back to the W-PWG or not according to the specific protection mode, Revertive or non-revertive. When protection switching takes place, if there are multiple P-PWGs, the service will be switched into the normal P-PWG that has the sub- highest preference level. 5. Security Considerations This document describes the applications of the Group ID, and it has the same security properties as in [PWE3-CTRL]. 6. IANA Considerations This document does not define the new extension, and need not the assignment by IANA. 7. Acknowledgments 8. References 8.1. Normative References [PWE3-CTRL] Luca Martini (ED), Toby Smith, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", draft- ietf-pwe3-control-protocol-17.txt, June 2005. Zhang Expires August 17, 2006 [Page 10] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 [PWE3-OAM] Thomas D. Nadeau, Monique Morrrow, Peter Busschbach, Mustapha Aissaoui, "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3-oam-msg-map-03.txt, September 2005. [PWE3-VCCV] T. D. Nadeau (ED), R. Aggarwal (ED), "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3- vccv-07, September 2005. 8.2. Informative References [PWE3-ARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985, March 2004. [PWE3-REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, January 2004. [PWE3-PROTECT] Ping Pan, "Pseudo Wire Protection", draft-pan-pwe3- protection, July 2005. [IANA] Luca Martini, "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15, November 2005. 9. Author's Addresses Haiyan Zhang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: zhanghaiyan@huawei.com Eric Li Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: xxl@huawei.com Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: dongjixiong@huawei.com Zhang Expires August 17, 2006 [Page 11] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 Yang Yang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: healthinghearts@huawei.com 10. 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 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. Zhang Expires August 17, 2006 [Page 12] Internet-Draft draft-zhang-pwe3-gid-app-00.txt February 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang Expires August 17, 2006 [Page 13]