Pseudo-Wire Edge-to-Edge (PWE3) Chi Yudong Internet Draft Kong Yong Expires: Jan 2005 Du Ke Wang Mingyi ZTE, Inc Jiang Lintao CATR of MII Editors July 2004 Scalable VPWS Network draft-yudong-pwe3-control-protocol-ext-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Jan 5, 2005. Abstract In the pwe3 framework, PW is provided between the egree nodes. In this case, full-mesh PSN tunnel and signaling session connections must be established between pwe3 PEs, which leads to the issue of scalability, especially the difficulty of cross-AS PW services. This document provides a reflector-based VPWS network framework, and presents a solution that provides cross-AS pwe3. 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]. Chi Yudong, et al. [Page 1] Internet Draft Scalable VPWS Network July 2004 Table of Contents 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 2 2 EXTENDED GID FEC ELEMENT . . . . . . . . . . . . . . . . . . 3 3 nexthop Information Contained in PW Label Message . . . . . 4 4 REFLECTOR . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 SIMPLE TRUNK MODE . . . . . . . . . . . . . . . . . . 6 4.2 "NEXTHOP SELF" MODE . . . . . . . . . . . . . . . . . 7 4.3 MULTIPLE REFLECTORS . . . . . . . . . . . . . . . . . 8 5 NEGOTIATION OF REFLECTOR SUPPORTABILITY . . . . . . . . . . 8 6 SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . . 10 7 CROSS-AS PW MODEL . . . . . . . . . . . . . . . . . . . . . 12 7.1 ASBR WORKING AS THE REFLECTOR . . . . . . . . . . . . . 12 7.2 ASBR NOT WORKING AS REFLECTOR . . . . . . . . . . . . . 12 8 COMPATIBILITY . . . . . . . . . . . . . . . . . . . . . . . 13 9 LOOP DETECTION . . . . . . . . . . . . . . . . . . . . . . . 13 10 IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 13 Intellectual Property Statement . . . . . . . . . . . . . . 15 14 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . 15 15 Copyright Statement . . . . . . . . . . . . . . . . . . . . 15 1 Introduction With the pseudo wire (PW) encapsulation and the transmission of L2 PDU, emulation L2 services are provided by going through the IP/MPLS backbone network. The network model that provides Pseudo Wire Emulation Edge-to-Edge(PWE3) services is presented in [1], and the Label Distribution Protocol (LDP) signaling mechanism to establish and maintain the PW is presented in [2]. However, the network models in [1] and [2] are flat. The egress-to-egress Packet Switched Network (PSN) tunnel and the direct signaling session connection between the Provider Edges(PEs) that provide PW must be established. When the network becomes extremely large, and the PW services on the backbone network increase in an explosive speed, the concern of scalability will be introduced. In addition, when cross-AS PW services are to be provided, issues to address include the establishment of a large number of cross-domain PSN tunnels(usually MPLS LSP tunnels) and LDP sessions. This document puts forward the solution of solving the network scalability issue with the network model that utilizes LDP reflectors to establish Virtual Private Wire Service (VPWS) network. In the scalable VPWS network, the PWE3 PE can establish signaling sessions separately with the reflectors, and provides cross-AS services with segments of PWE3. This document extends the PWE3 signaling: Chi Yudong, et al. [Page 2] Internet Draft Scalable VPWS Network July 2004 1. The extended GID (Generalized ID) FEC element is defined. Compared with the original GID FEC, the extended GID FEC contains Source PE LSR-ID and Target PE LSR-ID information. In this way, the extended GID FEC can independently identify a PW LSP. 2. The next-hop LSR-ID TLV is defined. The TLV may occur in the GID Label Messages. The function of the TLV is similar to the nexthop attribute in the Border Gateway Protocol (BGP). 3. The next-hop priority TLV is defined. The TLV may occur in the GID Label Messages. The function of the TLV is similar to the "local pref" attribute in the Border Gateway Protocol (BGP). 4. A extendible negotiation message and a negotiation mechanism is defined. 5. The establishment and maintenance mechanism of PW via reflector is defined. 6. The solution of establishing PW in segments via reflector is defined. 7. Cross-AS PW solution is provided. A bi-directional PW is in effect formed by two unidirectional LSPs. To make it simple, but maintain the generality, this document refers to the LSP in one data flow direction only if not otherwise specified. The ingress LSR in this direction is called ingress PE. Labels are sent from downstream to upstream, and therefore the signaling message direction and the LSP direction are reversed. For signaling, the downstream PE is called source PE, while the upstream PE is called target PE. 2 Extended GID FEC Element Each LSP of the PW is identified as follows: < Source PE, , Target PE, > [2] believes that LDP session connections between the source PE and the target PE should be established directly, and the label mapping messages are transmitted on the direct session connections to form PW. In this case, the GID FEC does not contain source PE and target PE informations, that is, GID FEC element is not sufficient to describe independently one PW. To enable that the PW label messages are trunked, this document extend the GID FEC element to include source PE and target PE, with the format as follows: Chi Yudong, et al. [Page 3] Internet Draft Scalable VPWS Network July 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 |C| PW Type |VC info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPE-LSRID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TPE-LSRID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2-1: Encapsulation Format of the Extended GID FEC Element In the encapsulation format of the GID FEC Element, SPE-LSRID TLV and TPE-LSRID TLV fields are added, one for the LSR Identification of the source PE, and the other for the LSR Identification of the target PE. The definition of other fields is completely the same as [2]. The FEC Type of the GID FEC Element uses 129 all the same. The TLV Type of the SPE-LSRID TLV and TPE-LSRID TLV is to be assigned by the Internet Assigned Number Authority (IANA). 3 nexthop Information Contained in PW Label Message The nexthop information can be contained in the PW Label Message as optional parameter. For more details, please refer to Section 7. Chi Yudong, et al. [Page 4] Internet Draft Scalable VPWS Network July 2004 To cope with the case with multiple reflectors, the PW label message can contain nexthop priority information. When the PE or the reflector receives multiple label mapping messages of the same PW LSP, with different nexthop's, the PE or the reflector can select the label in the PW label mapping message with large nexthop priority according to the nexthop pref value, as the PW LSP egress label. The encapsulation format of the next-hop LSR-ID TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEXTHOP-LSRID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3-1: The encapsulation format of the next-hop LSR-ID TLV The encapsulation format of the next-hop priority TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEXTHOP-PREF | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3-2: Encapsulation Format of next-hop pref TLV The TLV Type of the next-hop LSR-ID TLV and the next-hop priority TLV is to be assigned by the IANA. In this document, the type is assigned temporarily in the experimental TLV space as follows: next-hop LSR-ID TLV 0x3f02 next-hop Priority TLV 0x3f03 The PW label message may or may not contain next-hop LSR-ID TLV. If it contains no next-hop LSR-ID TLV, the adopter will consider by default nexthop LSR the source PE of the FEC TLV. The PW label message may not contain the next-hop pref TLV. If it does not contain the next-hop LSR-ID TLV, it should not contain the next-hop pref TLV, either. The pref value of the next-hop priority TLV ranges within 0~255. If the value of the next-hop LSRID TLV is consistent with the source PE of the FEC Element, the priority of the next-hop pref must be 255. If it is not consistent, it must be <255, ranging within 0~254. If the PW label message does not contain the next-hop LSR-ID TLV and the next-hop pref TLV, the priority is considered the higher, that is, 255. Chi Yudong, et al. [Page 5] Internet Draft Scalable VPWS Network July 2004 If the PW label message contain the next-hop LSR-ID TLV but without next-hop pref TLV, the priority is considered the lowest, that is, 0. 4 Reflector Reflector is added in the VPWS network to trunk the PW label messages between the PEs. The reflector has two working modes. One is the PW Label mapping mode for simple trunk, while the other is the nexthop self mode. 4.1 Simple Trunk Mode In the simple trunk mode, the reflector receives the PW label message, and simply forwards it to the proper LDP peers, as shown in Fig. 4-1. PW services are provided between PE1 and PE2. When the PW LSP is established in the PE1-->PE2 direction, there is no direct signaling session connection between PE1 and PE2, but they are all connected to the reflector through signaling session connections. PE2 sends the PW label mapping message to the reflector, and via the reflector, sends further to PE1. As the GID FEC element contains source PE and target PE messages, PE1 can correlate the PW label mapping message with the PW LSP in the PE1-->PE2 direction. Reflector +-----+ | R | +-----+ | | +-----+ | | PW Mapping | | PW Mapping | | L2 |VPWS |<--------------| |<----------------|VPWS | L2 VPN ==>|\ PE1| | | |PE2 /|==>VPN Intf | \ | +-----+ | / | Intf | \--|======================================>|--/ | +-----+ PSN Tunnel +-----+ Fig. 4-1: Reflector Networking in Simple Trunk Mode Similar to the PW Label mapping message, reflector can also transmit PW label messages of different types. The PW Label messages can also be trunked with multiple reflectors. The PE1, after trunked by the reflector, obtains the ingress label in the PE1-->PE2 direction for the PW LSP by PE2. In this case, PSN tunnel is to be established between PE1-->PE2. Chi Yudong, et al. [Page 6] Internet Draft Scalable VPWS Network July 2004 4.2 "nexthop self" Mode In the simple trunk mode, the reflector only participates in the PW establishment and maintenance processes at the control level, without participating in data forwarding unless it works as P router in the PSN tunnel. In this case, the N2 issue in the PSN tunnel is not solved yet. In the "nexthop self" mode, the reflector participates in the L2 PDU forwarding of PW. The reflector assigns label to the PW LSP, notifying PE via the nexthop tlv that the label is assigned by the reflector, and requires that the PSN tunnel between the PE and the reflector send the L2 PDU of the PW to the reflector, which will further send to the far-end PE. As shown in Fig.4-2, the reflector receives the PW label mapping of the PE2, with the PW label value being L1. The reflector assigns related ingress L2 to the PW LSP, bundles it with the PW label mapping of PE2, and writes it into the Label Information Base (LIB). The reflector does not trunk the PW label mapping message of PE2 to PE1 simply. It replaces the label value (L1) in the original Label TLV with the label value (L2) that it assigns, and adds or modifies the nexthop LSRID tlv in the message into its own LSR ID, notifying PE to select the PSN tunnel 1 between the reflectors as the PW tunnel. When the reflector receives on the PSN tunnel 1 the data packet encapsulated with its own PW LSP ingress label, it will replace it with the PW LSP label assigned by PE2, then forwards the data packet to PE2 on PSN tunnel 2. Reflector Source PE = PE2 Dest. PE = PE1 +-----+ Source PE = PE2 Nexthop = R | R | Dest. PE = PE1 +-----+ Label = L2 | | Label = L1 +-----+ | | PW Mapping | | PW Mapping | | |VPWS |<----------------| |<------------------|VPWS | ==>| PE1|================>| |==================>|PE2 |==> | | PSN Tunnel 1 +-----+ PSN Tunnel 2 | | | | | | +-----+ +-----+ Fig.4-2: Reflector Networking in the "nexthop self" Mode The network in the nexthop mode is similar to the data layer of the segmented PW network. In Fig. 4-3, PW1 is established between the L2 VPN interface of PE1 and a L2 VPN interface (or virtual interface) of the router R, while PW2 is established between the Chi Yudong, et al. [Page 7] Internet Draft Scalable VPWS Network July 2004 L2 VPN interface of PE2 and another L2 VPN interface (or virtual interface) of the router R. The two L2 VPN interfaces on the router R are shorted and the PW services between PE1 and PE2 are provided. The difference between the two solutions is that in Fig. 6, PW is configured, established, and maintained between the PE router and the router R, PE administrator needs to know the location of the router R, and the router R should be configured with related PW information. In the case that the router R participates in a large amount of PW services, it is concerned with extendibility. In the reflector networking in the "nexthop self" mode, PW is still configured between the PEs. The reflector is transparent to the PEs administrator, and does not need to configure specific PW LSP. The PW LSP information for the reflector is obtained by learning. +-----+ | | L2 |VPWS | +-----+ VPN ==>| PE1|<----------------| R | Intf | |================>| |==+ L2 Intf 1 | | PSN Tunnel 1 | | | +-----+ | | | | | |(shorted) +-----+ | | | L2 | |---------------->| | | VPN <==|VPWS |<================| |==+ L2 Intf 2 Intf | PE2| PSN Tunnel 2 +-----+ | | | | +-----+ Fig. 4-3: Segmented PW Network 4.3 Multiple Reflectors When the network has multiple reflectors, PE may receive multiple PW label mappings. If one or more reflectors adopt the "nexthop self" mode, the nexthop values of the mapping messages received by the PE are different. The network administrator can assign priority to the reflector in the nexthop mode, and put the priority information in the mapping message. PE selects the nexthop with higher priority according to the nexthop priority tlv in the mapping message. If the nexthop priority values are the same, the nexthop value can be used to differentiate them. The flow equalization strategy can be adopted to share the load of multiple nexthops. 5 Negotiation of Reflector Supportability The PE and the reflectors should not send the PW label messages with GID FEC element, nexthop LSRID TLV, and nexthop priority TLV to the PE that does not support reflectors. Before sending the PW label message extended in this document, the reflector supportability needs to be negotiated. Chi Yudong, et al. [Page 8] Internet Draft Scalable VPWS Network July 2004 To maintain the stability of the LDP session connection and reduce the influence on other LDP services, this document does not extend the negotiation function, which is achieved in phase of "Session Initialization". It designs another type of LDP extendibility negotiation message. With this type of LDP extendibility negotiation message, the LDP peers can negotiate dynamically or re-negotiate the reflector supportability and its future LDP extendibility. The encapsulation format of the LDP extendibility negotiation message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| CN Message Type(0x3f00) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig.5-1: Encapsulation of the LDP Extendibility Negotiation Message The optional parameters in the message is encapsulated with TLV format. Currently there are two defined negotiation capabilities: reflector supportability and local reflector capability. In the case of reflector supportability the TLV encapsulation format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RC(0x3f00) | Length (1) | 0/1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: Reflector extendibility not supported 1: Reflector extendibility supported Fig. 5-2: TLV Encapsulation of LDP Reflector Supportability TLV encapsulation format of the local reflector capability is as follows: Chi Yudong, et al. [Page 9] Internet Draft Scalable VPWS Network July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LRC(0x3f01) | Length (1) | 0/1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: The local is not a reflector. 1: The local is a reflector. Fig. 5-3: TLV Encapsulation of the LDP Local Reflector Capability The reflector supportability TLV notifies the LDP peer whether reflector extendibility PW label message that carries extended GID FEC element, nexthop LSRID TLV, and nexthop pref TLV can be sent to the local LSR. The local reflector capability TLV notifies the LDP peer whether LSR is a reflector. After the session establishment enters the Operational status, and when the local reflector supportability changes, the LDP router will notifies the LDP peer of its own corresponding capability value. When the LDP router receives the extendibility negotiation message from the peer, it will trace the capability changes of the peer. Concerning the reflector supportability extended by this document, the PW label mapping should be sent or canceled accordingly. If no extendibility negotiation message of the peer is received, the far-end does not have any extendibility. When the LSR that does not support extendibility negotiation message receives the extendibility negotiation message, the message can be discarded. 6 Specification This chapter describes in detail the signaling processing process. Like [2], in the VPWS network, the LDP speaker is required to adopt the Label Distribution Unsolicited Downstream mode to distribute PW labels. The slight difference is that the label in [2] is transmitted between the PEs, and therefore it is not concerned with the Independent Label Distribution Control Mode or the Ordered Label Distribution Control Mode. This document requires that all the LDP speakers that participated in the PW label distribution, including the PE router and reflector, adopt the Ordered Label Distribution Control Mode. That is, it is required that the LSR can send the label mapping message to upstream PEs or to the reflector only Chi Yudong, et al. [Page 10] Internet Draft Scalable VPWS Network July 2004 when the LSR receives the downstream PW label mapping message, or when the LSR is the egress PE of the PW. All the LDP speakers in the VPWS network should adopt the Liberal Label Retention Mode to keep the PW label, which is the same as [2]. If PE does not support the reflector extendibility defined in this document, PW label is only distributed to the PE router on the other end of the PW. If PE supports the reflector extendibility, all the signaling neighbors that work as reflectors can be learned via extendibility negotiation. PE will take the initiative to distribute PW label to the PE router on the other end of the PW (if there is direct signaling session), and will also take the initiative to distribute PW labels to all reflectors. The reflector will trunk the label mapping message to other reflector or to the target PEs of the PW label mapping message only when it receives the label mapping message from downstream PEs or the downstream reflectors. If the reflector itself is the egress router of the PW, it plays the role of PE router, which means that it will take the initiative to distribute PW labels to other reflectors and the target PEs. If the reflector itself is the target PE of the PW label mapping message, it is in effect the target PE of the PW label mapping. It will not forward label mapping message to any neighbors. If the target PE of the PW label mapping message does not support reflector extendibility, the reflector should not forward PW label mapping message to the target PE. If the reflector receives the PW label mapping message from the neighbor that does not support reflector extendibility, it should be considered that the target PE of the label mapping message is the current reflector. If it contains the message property extended by this document, it is considered that a fatal error occurs, and the session will be terminated. When the target PE of the PW label mapping receives the PW label message from the reflector or the downstream PEs, it can select the best egress labels according to the priority or the default priority carried in the label mapping message, or can adopt a certain load equalization strategy to perform load sharing of the L2 PDU received from the L2 VPN on different PWs. What is important is that it must select the tunnel to the next-hop LSR carried by the label mapping message (or by default) as the PSN tunnel (external tunnel). If all the label mapping received by the reflector is cancelled, Chi Yudong, et al. [Page 11] Internet Draft Scalable VPWS Network July 2004 it will send label cancel message to the target PE or other reflectors. 7 Cross-AS PW Model The LDP itself does not concern the concept of autonomous system. Generally, the LDP is the label distribution protocol within the autonomous system. When cross-AS PW services are to be provided, to establish a large amount of cross-AS LDP signaling sessions are not suitable. The administrators of the autonomous system can negotiate with each other to determine the limited LDP sessions between the autonomous systems, and implement cross-AS PW establishment and maintenance. There are two models to establish and maintain cross-AS PWs via the reflector extendibility. 7.1 ASBR Working As the Reflector The first model is ASBR (or ASBLSR), which works as reflector, working in the "nexthop self" mode. In this networking topology, the L2 PDU received at the L2 VPN interface of the PE will be first encapsulated in the PW label allocated by the ASBLSR-1, and is sent to the ASBLSR-1 on the PSN Tunnel 1 between PE1 and ASBLSR-1. It is again replaced into PW label allocated by the ASBLSR-2, and is sent to the ASBLSR-2, and is replaced into PW label allocated by the PE2, is further transmitted to PE2 on the PSN Tunnel 2 between the ASBLSR-2 and PE2. Finally it will be forwarded to the L2 VPN of PE2. In this model, the PSN tunnel is not needed between the ASs. It adopts the PW label to cross the ASs. 7.2 ASBR Not Working as Reflector In the second model, the ASBR does not work as reflector. Reflector is arranged differently between the two autonomous systems, working in the "nexthop self" mode. In this networking topology, the L2 PDU received at the L2 VPN interface of the PE will be first encapsulated in the PW label allocated by the reflector 1, and is further sent to the reflector 1 on the PSN Tunnel 1 between PE1 and reflector 1. The PW label is replaced into the PW label allocated by the reflector 2, and is further sent to the reflector 2 on the PSN Tunnel 2 between the reflector 1 and the reflector 2. Label replacement is done again, and it is sent to PE2 on the PSN Tunnel 3 between the reflector 2 and PE2. Finally it is forwarded to the L2 VPN interface on PE2. Chi Yudong, et al. [Page 12] Internet Draft Scalable VPWS Network July 2004 In this model, a PSN tunnel from reflector to reflector between the ASs, and PSN tunnel label is used to cross the ASs. The cross-AS PSN LSP tunnel is established by the LDP signaling, or by the RSVP-TE signaling, which is not in the discussion of this document. Of course, the reflectors in the two models can adopt simple trunk mode, but in this case, more cross-AS PSN tunnels are to be established. It is more suitable perhaps on the occasions where the QoS of the PW is stressed. 8 Compatibility In this document, as for the reflector capability of the LDP speaker in the extended VPWS network, the LDP speaker realized as per [2] does not support this capability. To be compatible with the equipment compliant with [2] standard, the LDP speaker supporting the LDP reflector capability must negotiate with its neighbors on the reflector capability, and does not send any messages carrying the document extension information to any neighbors who do not support the reflector capability. Of course, the equipment that does not support the reflector capability extension cannot establish and maintain the pseudo wire through the reflector. On the other side, the reflector capability discussed in this document refers to the support capability of the PW label message reflector, which is used only for PW establishment and maintenance, without affecting the function of LDP to set up and maintain LSPs for other types of FECs. 9 Loop Detection We have noted that, when multiple reflectors are connected in a full mesh manner, the "mutual fraud" will occur. That is, Reflectors A and B learn the PW label from the egress PE, Reflector A trunks to Reflector B, and Reflector B re-trunks to Reflector A, so when Egress PE cancels the PW service, Reflectors A and B will not be able to send label cancel message to each other due to the label mapping message of the other. As a result, the data from the target PE may form a loop between Reflectors A and B. In this case, the reflector shall have the capability to support the loop detection as prescribed in RFC3036, that is, the loop detection capability based on path vector and hop count. Chi Yudong, et al. [Page 13] Internet Draft Scalable VPWS Network July 2004 10 IANA Considerations (To be filled in in a later revision.) 11 Acknowledgments The authors wish to thank all the people who have contributed to this document through numerous discussions. References: [1] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-04.txt (work in progress), August 2003. [2] Martini, L. et al, " Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-06.txt, October 2003, (work in progress) [3] "Virtual Private LAN Services over MPLS", draft-ietf-l2vpn-vpls-ldp-01.txt, Work in progress, November 2003 12 Authors' Addresses Authors' Addresses Jiang Lintao CATR of MII CHINA Email: jianglt@public.bta.net.cn Chi Yudong ZTE Inc. CHINA Email: chi.yudong@zte.com.cn Kong Yong ZTE Inc. CHINA Email: kong.yong@zte.com.cn Du Ke ZTE Inc. CHINA Email: du.ke@zte.com.cn Wang Mingyi ZTE Inc. CHINA Email: wang.mingyi@zte.com.cn Chi Yudong, et al. [Page 14] Internet Draft Scalable VPWS Network July 2004 13 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. 14 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. 15 Copyright Statement Copyright (C) The Internet Society (2004). 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. Chi Yudong, et al. [Page 15]