Network Working Group Chi Yudong Internet Draft Cagatay Buyukkoc Expiration Date: Jul 2005 Du Ke Kong Yong Wang Mingyi ZTE, Inc. Jiang Lintao CATR of MII Jan 2005 Multi-Hop Pseudo-Wires Signalling Using LDP draft-yudong-pwe3-control-protocol-ext-01.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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a signalling solution for setup and maintenance of multi-hop pseudo-wires. This signalling solution is a natural extention of the method described in "Pseudowire Setup and Maintenance using LDP" [PWE3-CTRL]. The main purpose of this document is to solve the scaling issues in single hop pseudo-wire architectures. Chi Yudong, et al. [Page 1] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 Table of Contents 1. Specification of Requirements . . . . . . . . . . . . . . 2 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 2 3. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 4. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 5. Extended GID FEC Element . . . . . . . . . . . . . . . . 4 6. Nexthop Information Contained in PW Label Message . . . 7 7. Reflector . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Capability Negotiation . . . . . . . . . . . . . . . . . 9 10. Specification . . . . . . . . . . . . . . . . . . . . . 11 11. Loop Detection . . . . . . . . . . . . . . . . . . . . . 12 12. Compatibility . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . 13 14. Security Considerations . . . . . . . . . . . . . . . . 13 15. Full Copyright Statement . . . . . . . . . . . . . . . . 13 16. Intellectual Property Statement . . . . . . . . . . . . 13 17. Normative References . . . . . . . . . . . . . . . . . 14 18. Informative References . . . . . . . . . . . . . . . . 14 19. Author Information . . . . . . . . . . . . . . . . . . 14 1. Specification of Requirements 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. Acknowledgements The editors gratefully acknowledge Richard Spencer (British Telecom), Peter Busschbach (Lucent), whose comments contributed greatly to the the notion of routing of PW label messages. We would also like to thank the authors of [PWE3-CTRL], since that document is the basis of our work. 3. Introduction With the pseudo wire (PW) encapsulation and the transmission of L2 PDU, emulation of 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 [PWE3-ARCH], and a signaling mechanism to setup and maintain the PW is presented in [PWE3-CTRL] using the the Label Distribution Protocol (LDP). However, the network models in [PWE3-ARCH] and [PWE3-CTRL] are flat. A full mesh egress-to-egress Packet Switched Network (PSN) tunnels Chi Yudong, et al. [Page 2] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 and direct signaling sessions connection between the Ultimate Provider Edges (U-PEs) must be established. When the network becomes extremely large, scalability problems arise. In addition, when inter-AS PW services are to be provided, issues to address include the establishment of a large number of inter-domain PSN tunnels (usually MPLS LSP tunnels) and LDP sessions. This is a requirement described in more detail in [PWE3-MHREQ]). This document puts forward the term of LDP reflectors, as a S-PE, to solve the scaling issue mentioned above. The main motivation is to reduce the number of pseudo-wires signaling (LDP) session connections and the number of PSN tunnels on which PWs are carried. Most common use of pseudo-wires (MH-PW and/or SH-PW) will be provided on a MPLS/IP backbone network and the PSN tunnels, on which PWs are carried, will be set up and maintained by LDP signalling, as P-to-MP MPLS tunnels. The method described here apply to some of the concerns raised above and will not address all cases described in [PWE3-MHREQ]. This document provides a solution to the scaling issue in the MH-PW network model as described in [PWE3-MHREQ]. In the scalable PW service network, a S-PE works as a LDP reflector. LDP-capable U-PEs establish signaling sessions separately with the reflectors. Reflector switches PW Label messages from U-PE to remote U-PE. The reflector has two modes to switch PW Label messages. One is simple relay mode, the other is the nexthop-self mode. In the simple relay mode, the reflector receives the PW label message, and simply forwards it to the proper LDP peers, as shown in Fig. 1. Reflector +-----+ | R | +-----+ | | +-----+ | | PW Mapping | | PW Mapping | | |VPWS |<--------------| |<----------------|VPWS | AC ==>|U-PE1| | | |U-PE2|==> AC | \ | +-----+ | / | | \--|======================================>|--/ | +-----+ PSN Tunnel +-----+ Fig. 1: Reflector Networking in Simple relay Mode PW services are provided between U-PE1 and U-PE2. When the PW LSP is established in the U-PE1-->U-PE2 direction, there is no direct signalling session connection between U-PE1 and U-PE2, but they are all connected to the reflector (R). U-PE2 sends the PW label mapping message to the reflector, and via the reflector, sends further to U-PE1. Chi Yudong, et al. [Page 3] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 The U-PE1, relayed by the reflector, obtains the outgoing label of the PW LSP assigned by PE2. In this case, U-PE2 is the next hop of PW, and PSN tunnel is needed between PE1-->PE2. Working in the simple relay mode, the reflector only participates in the PW setup and maintenance processes at the control level, without participating in data forwarding unless it works as P router in the PSN tunnel. While working in the "nexthop self" mode, the reflector participates in the data forwarding of PW. After receiving PW label mapping from downstream (U-PE or S-PE), the reflector itself assigns an ingoing label to the PW LSP, and switchs mapping message to upstream with the label which is assigned by downstream device (U-PE or S-PE) replaced and an additional nexthop LSR-ID TLV added which indicates the right next hop of the MH-PW with reflector's LSRID value as shown in Fig. 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 | | AC |VPWS |<----------------| |<------------------|VPWS |AC ==>|U-PE1|================>| |==================>|U-PE2|==> | | PSN Tunnel 1 +-----+ PSN Tunnel 2 | | | | | | +-----+ +-----+ Fig. 2: Reflector Networking in the "nexthop self" Mode In this Cases, PSN tunnels are set up between upstream device (U-PE1) and reflector, and between reflector and downstream device(U-PE2). And reflector participates in forwarding of PW's data. This document extends the PWE3 signaling as follows: 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. This TLV may present in the GID Label Messages. The function of the TLV is similar to the nexthop attribute in the Border Gateway Protocol (BGP). Chi Yudong, et al. [Page 4] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 3) The next-hop priority TLV is defined. The TLV may present 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. This message is used to discover each other by reflector (S-PE) and U-PE, which are implemented according this document. 5) The establishment and maintenance mechanism of MH-PW via reflectors is defined. A bi-directional PW (either SH-PW or MH-PW)is in effect formed by two unidirectional LSPs. Unless otherwise stated, this document refers to the LSP in one data flow direction only. The ingress LSR in this direction is called ingress U-PE. Labels are sent from downstream to upstream, and therefore the signalling message direction and the LSP direction are reversed. For signalling, the downstream U-PE is called source U-PE, while the upstream U-PE is called target U-PE. 4. Terminology The term "LDP reflectors" originates from Border Gateway Protocol (BGP), and the term "Switching point (S-PE)" is defined in [PWE3-MHREQ]. 1) LDP reflectors: An LDP-capable S-PE, which switch LDP PW-Label messages received from one LDP session to other LDP session(s). 2) PW control protocol: Either in SH-PW case, or in MH-PW case, PW control protocol is used to setup and maintain PW between two PW access points with PW access point addresses. MH-PW control protocol need both source access point address and sink access point address of the PW or PW segment. An S-PE may or may not have an access point address. 5. Extended GID FEC Element Each LSP of the PW is identified as follows: < Source PE, , Target PE, > Chi Yudong, et al. [Page 5] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 They are in fact the access point addresses of PW: < source access point address, sink access point address > [PWE3-CTRL] states that LDP session connections between source U-PE and target U-PE should be established directly, and the label mapping messages are transmitted on the direct session connections to set up the SH-PW. In this case, the GID FEC does not contain information about source U-PE and target U-PE. Therefore, GID FEC element is not sufficient to describe the PW. To enable the PW label messages being trunked, this document extends the GID FEC element to include identifications of source U-PE and target U-PE, with the formats shown in Fig. 3. 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. 3: Encapsulation Format of the Extended GID FEC Element Chi Yudong, et al. [Page 6] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 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 U-PE, and the other for the LSR Identification of the target U-PE. The definition of other fields is completely the same as [PWE3-CTRL]. The FEC Type of the GID FEC Element uses element type 129. The TLV Type of the SPE-LSRID TLV and TPE-LSRID TLV is to be assigned by the Internet Assigned Number Authority (IANA). 6. Nexthop Information Contained in PW Label Message The nexthop information can be contained in the PW Label Message as an optional parameter. For more details, refer to Section 7. To inform upstream U-PE or S-PE that the PW label mapping is modified by itself (S-PE), the reflector adds next-hop LSR-ID TLV into mapping message. Its value is the LSR identification of the reflector. The encapsulation format of the next-hop LSR-ID TLV is shown in Fig 4. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEXTHOP-LSRID | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 4: The encapsulation format of the next-hop LSR-ID TLV To adapt to the case with multiple reflectors, the PW label message can contain nexthop priority information. When upstream U-PE or S-PE receives multiple label mapping messages of the same PW LSP (identified by Extended GID FEC Element) with different nexthops, it can select the label in the PW label mapping message with the highest nexthop priority as outgoing label. The priority is a configurated parameter of a reflector. It should be configurated either a priority per device, or a priority per group of PW according to defined policies. The encapsulation format of the next-hop priority TLV is shown in Figure 5. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEXTHOP-PREF | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 5: Encapsulation Format of next-hop pref TLV Chi Yudong, et al. [Page 7] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 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 highest, that is, 255. If the PW label message contain the next-hop LSR-ID TLV but without next-hop pref TLV, the priority is considered the lowest, i.e. 0. 7. Reflector Reflector is an LDP-capable S-PE, which can switch PW label messages received from one LDP session to other LDP session(s). In Fig. 1 & Fig. 2, it is shown how a reflector switches PW mapping messages. Similarly, reflector can also switch other types of PW label messages, including release messages, withdraw messages, request messages, and abort messages (In fact, this document suggests LDP DU mode being adopted, and no request messages and abort messages will appear in the network). A PW Label message can also be switched to multiple upstream devices (for mapping message and withdraw message) or downstream device (for withdraw message, request message, and abort message). The reflector has two modes to switch PW Label messages. One is simple relay mode, the other is the nexthop-self mode. A reflector should be able to simply relay label messages for special groups of PWs, whilst switching other PW label messages in the nexthop-self mode, according to policies of the network. It is worth emphasizing that, a reflector is only an intermediate device (S-PE) without PW layer access point address for the Chi Yudong, et al. [Page 8] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 corresponding MH-PW. 8. Routing U-PE and reflector need routing information to find the next hop of PW mapping messages and request messages. U-PE and reflector send PW mapping messages and request massages to peers only if: 1) the peer is the target of PW mapping message or request message. 2) the peer is the eBGP NEXT_HOP to the target of PW mapping message or request message. (e.g., the peer is the e-BGP advertiser of the route for the target U-PE) 3) the peer is the IGP next hop for the target of PW mapping message or request message. 4) the peer resides in the closest AS in the best path towards the target of PW mapping message or request message. If multiple LDP peers reside in the closest AS, the peer with the highest IP address is the one that PW mapping message or request message should be sent. 5) the peer is configured as the static next-hop peer for the target of PW mapping message or request message. 6) if no peer can be found according with conditions listed above, U-PE and reflector SHOULD send PW mapping messages and request messages to all reflectors with which it has signalling relationships. U-PE and reflector send PW release messages, withdraw message and abort messages to the peer according LDP specification [LDP]. 9. Capability Negotiation U-PE SHOULD NOT send the PW label messages with GID FEC element, nexthop LSRID TLV, and nexthop priority TLV to a U-PE that can't handle this information. Reflector SHOULD NOT switch label messages to any peer that does not support reflector functionality. Before sending the PW label message proposed in this document, the Capability of device MUST be negotiated. A reflector MUST announce its Capability to switch PW label messages, and U-PE MUST announce its Capability to receive PW label messages switched by reflectors. 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 the initial phase of Chi Yudong, et al. [Page 9] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 "Session Initialization". This document proposes 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 Capability to support reflectors and other future LDP extensions. The encapsulation format of the LDP Capability negotiation message is shown in Figure 6. 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. 6: Encapsulation of the LDP Capability Negotiation Message The optional parameters in the message is encapsulated with TLV format. Currently there are two defined capabilities: 1) capability to receive PW label messages switched by reflector (for U-PE). 2) capability to switch PW label messages (for reflector). The capability to receive PW label messages switched by a reflector is indicated in reflector supportability TLV. Its encapsulation format is shown in Fig. 7. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RC(0x3f00) | Length (1) | 0/1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: incapable to receive PW label messages switched by reflector 1: capable to receive PW label messages switched by reflector Fig. 7: TLV Encapsulation of LDP Reflector Supportability The capability to switch PW label messages is indicated in local reflector capability TLV. Its encapsulation format is shown in Fig. 8. Chi Yudong, et al. [Page 10] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LRC(0x3f01) | Length (1) | 0/1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0: The LSR itself is not a reflector. 1: The LSR itself is a reflector. Fig. 8: TLV Encapsulation of the LDP Local Reflector Capability The reflector supportability TLV notifies the LDP peer whether the PW label message that carries extended GID FEC element, nexthop LSRID TLV, or nexthop pref TLV can be sent to the local LSR. The local reflector capability TLV notifies the LDP peer whether the LSR is a reflector. After the LDP session gets the Operational status, Peers send LDP Capability Negotiation Message to each other. Once the capability of one LSR changed due to configuration, a new Capability Negotiation Message MUST be sent to peers. When the LDP router receives the Capability Negotiation Message from the peer, it MUST trace the capability changes of the peer. The PW label messages 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 which does not support Capability Negotiation Message receives the Capability Negotiation Message, the message can be discarded. 10. Specification This section describes detailed signaling of the proposed framework. As in [PWE3-CTRL], the LDP-capable U-PE and reflector SHOULD adopt the Label Distribution Unsolicited Downstream mode to distribute PW labels. Since reflectors has no prior information about MH-PW in which they perform as an S-PE, the reflector MUST NOT maintain any state of a MH-PW before it starts switching label messages. The reflector can send (switch) the PW label message to upstream/downstream devices (U-PEs or S-PE) only when the reflector receives a corresponding PW label message from downstream/upstream. All the LDP-capable U-PE and reflectors MUST adopt the Liberal Label Retention Mode to keep the PW label, which is the same as in [PWE3-CTRL]. Chi Yudong, et al. [Page 11] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 If U-PE does not support the extension defined in this document, PW label is only distributed to the U-PE on the other end of the PW. If U-PE supports the extension under discussion, all reflectors can be discovered via Capability Negotiation. U-PE MUST take the initiative to distribute PW label to the target U-PE on the other end of the PW, by the appropriate next hop that is decided by routing. The reflector MUST switch the label mapping message to the target U-PEs using the next hop that is also decided by routing. If the reflector itself is the egress router of the PW, it plays the role of U-PE, and it MUST take the initiative to distribute labels of PW that end at it. If the reflector itself is the target PE of the PW label mapping message, It MUST NOT switch label mapping message to any neighbors. If the target U-PE of the PW label message does not support this extension, any PW label message targeted to it MUST be discarded and it provides a return Notification of this action. If U-PE and reflector receives a PW label mapping message with TLV extended by this document from a neighbor that does not support the extension under discussing, it SHOULD be considered that a fatal error occurs, and the session MUST be terminated. When a U-PE receives several label mapping for same PW simultaneously from reflector(s) and/or the downstream U-PE, it SHOULD select the best outgoing labels according to the priority or default priority carried in the label mapping message. It MUST select the tunnel to the next-hop LSR carried in the label mapping message (or by default) as the PSN tunnel. If all received label mapping for a MH_PW are withdrawn, the reflector MUST send corresponding label withdraw to the target U-PE or other reflectors, and MUST cancel all status about that MH-PW after receiving all label release responses. 11. Loop Detection We have noted that, when multiple reflectors are connected in a full mesh, all U-PEs and reflectors route PW label messages independently, a "routing loop" may be created. As an example, Reflector B receives a MH-PW label mapping from the U-PE A, and switchs it to Reflector C. Reflector C might decide that reflector B is the next hop towards target U-PE D, and re-switchs it back to Reflector B. In this case, the reflector shall have the capability to support the Chi Yudong, et al. [Page 12] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 loop detection as prescribed in RFC3036, that is, the loop detection capability based on path vector and hop count. 12. Compatibility To be compatible with the equipment compliant with [PWE3_CTRL] standard, the LDP-capable U-PE and S-PE MUST negotiate with its neighbors on the capability, and MUST not send any messages carrying extension information described in this document to any neighbors who do not support the extended capability. Of course, the equipment that does not support the extension cannot set up and maintain the MH-PW through a reflector. On the other hand, the extension capability discussed in this document refers to the support capability of the PW label message reflector, which is used only for MH-PW setup and maintenance, without affecting the function of LDP to set up and maintain LSPs for other types of FECs. 13. IANA Considerations (To be filled in in a later revision.) 14. Security Considerations To be determined later. 15. Full 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. 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. 16. 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 Chi Yudong, et al. [Page 13] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 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. 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. 17. Normative References [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-07.txt ( work in progress ), March 2003. [PWE3-CTRL] " Pseudowire Setup and Maintenance using LDP", Martini, L. et al., draft-ietf-pwe3-control-protocol-14.txt, (work in progress), December 2004 18. Informative References [ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995 [PWE3-MHREQ] "Requirements for inter domain Pseudo-Wires", Martini, L. et al., draft-martini-pwe3-MH-PW-requirements-00.txt, (Work in progress), December 2004 19. Author Information Jiang Lintao CATR of MII CHINA Email: jianglt@public.bta.net.cn Chi Yudong, et al. [Page 14] Internet Draft Multi-Hop Pseudo-Wires Signalling Using LDP July 2004 Cagatay Buyukkoc ZTE Inc. USA Email: ckoc@zteusa.com 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 15]