Network Working Group Zheng Huang Internet Draft Yang Yang Huawei Expires: December 2006 June 16, 2006 The Solution of Label Collision Between Multicast and Unicast draft-huang-lable-collision-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 December 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract Upstream Label Suggestion and upstream label allocation schemes are introduced and simply defined in [OVER][UPSTREAM]. But it is possible that the same label will be allocated for unicast LSP and multicast LSP on the same link. In upstream label allocation, it solves the collision through layer 2 encapsulation and context-specific label Huang Expires December 16, 2006 [Page 1] Internet-Draft draft-huang-lable-collision-00.txt June 2006 space. But in the Upstream Label Suggestion allocation scheme, the collision can not be solved if downstream LSRs do not support context-specific label space. This document details the solution of label collision between multicast and unicast for the Upstream Label Suggestion allocation scheme. 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. Collision Scene.............................................3 3. Label collision solution.....................................4 4. Upstream Label Suggestion for Multicast......................4 5. Some Advice.................................................5 6. IANA Considerations.........................................6 7. References..................................................6 7.1. Normative References....................................6 7.2. Informative References..................................6 8. Author's Addresses..........................................6 9. Intellectual Property Statement..............................6 Disclaimer of Validity.........................................7 Copyright Statement............................................7 Acknowledgment.................................................7 1. Introduction On multi-access links for P2MP LSPs, a labeled packet is delivered to multiple routers. All next-hop downstream routers will receive the packet with the same label. In order to optimize packet transmission and avoid branch LSR traffic replication for P2MP LSPs, all next-hop downstream routers must process the same label. This will sit well with upstream Label Suggestion and upstream label allocation schemes [OVER] [UPSTREAM]. When unicast label is allocated before multicast label, it is possible that the same label will be allocated on the same LSR for unicast LSP and multicast LSP on the same link. The unicast LSP and the multicast LSP will use the same incoming label value on the same data link. This means one label collision between multicast and Huang Expires December 16, 2006 [Page 2] Internet-Draft draft-huang-lable-collision-00.txt June 2006 unicast. In upstream label allocation, it solves the collision through layer 2 encapsulation and context-specific label space. But in the Upstream Label Suggestion allocation scheme, the collision can not be solved if downstream LSRs do not support context-specific label space. This document details the solution of label collision between multicast and unicast for the Upstream Label Suggestion allocation scheme. 2. Collision Scene By way of illustration, the figure below demonstrates the scene of the collision between multicast label and unicast label. D / / A---B---C---E \ \ F There already exists one unicast LSP (A-B-C-E). And the incoming label on LSR C is equal to K. There also exist one multicast tree (A-B, B-D, B-F). And the incoming label on LSR D and LSR F is equal to K. LSR D and LSR F are the next- hop downstream router of LSR B, and their incoming labels must same. Subsequently, LSR C wants to join the multicast tree. LSR C will also become the next-hop downstream router of LSR B. The incoming multicast label on LSR C must be equal to K, just like LSR D and LSR F on the same multicast tree. So there will appear the two same incoming labels on LSR C if we don't distinguish between multicast and unicast. The collision can be solved very well in [UPSTREAM]. But in the Upstream Label Suggestion allocation scheme, these multicast labels are assigned by downstream LSRs just like unicast. The collision can not be solved if downstream LSRs do not support context-specific label space. As a result, all next-hop downstream LSRs can not hold the same label in multicast tree and the traffic can not be optimized. Huang Expires December 16, 2006 [Page 3] Internet-Draft draft-huang-lable-collision-00.txt June 2006 3. Label collision solution This document proposes one solution for label collision. When collision appears, unicast will drop the label to multicast and re- assign one new different label for itself. Then multicast tree can be built successfully. The solution needs to extend label distribution instructions, for example, LDP or RSVP-TE. We give one vivid description based on LDP Mechanisms as follows. Unicast labels are conventionally assigned by one downstream LSR. In multicast, labels can be assigned by one upstream or downstream LSR. In upstream label assignment, the collision can be resolve when all LSRs support Upstream Label Assignment and Context Specific Label Space. It is possible that the capability of Context Specific Label Space is not supported in Upstream Label Suggestion allocation scheme. So the collision question still exists. We assume the collided label is equal to K. When Downstream LSR detects a collision, unicast LSP will give up the collided label and reassign one new unicast label. So the multicast can use the label K to build one entire tree. 4. Upstream Label Suggestion for Multicast In Upstream Label Suggestion for Multicast scheme, all of multicast labels are assigned by all downstream LSRs. The message exchange for Multicast Upstream Label Suggestion is shown in the figure below to resolve the label collision between two adjacent LSRs. The figure shows one detailed process of downstream unsolicited label with Suggestion label distribution. There include there stages in the message exchanges between two adjacent LSRs: a) Downstream LSR assigns label to upstream LSR based on Upstream Label Suggestion for Multicast. When downstream LSR sends Label Mapping message with special label to it, upstream LSR will realize that downstream wants one suggested label according to the special label. Upstream LSR returns Label Request with one suggested label to downstream LSR. b) Downstream LSR defect the collision, and unicast will assign one new different label after abandoning the collided label. The suggested label value is equal to the value of unicast label in the same downstream LSR. So the downstream LSR will defect a label Huang Expires December 16, 2006 [Page 4] Internet-Draft draft-huang-lable-collision-00.txt June 2006 collision and can not assign the label for multicast. Consequently, downstream LSR will give up the collided label during sending Label Withdraw message and accepting Label Release message from the upstream LSR in unicast LSP. Then downstream LSR assigns one new label for unicast again. c) Downstream LSR re-assigns the label to upstream LSR for Multicast. After unicast gives up the label, downstream LSR will find that the label is available for multicast and the collision disappears. So it will re-assign the label to upstream LSR for multicast by using Label Mapping message again. It must be noticed that the first message is not used in Downstream On-Demand label distribution. Upstream LSR Downstream LSR | Label Mapping | | (Special Label) | (Multicast) |<------------------------------| | Label Request | | (Suggested Label = K) | (Multicast) |------------------------------>| | | (Detect a collision) | Label Withdraw | (Unicast give up label) | (Label = K) | (Unicast) |<------------------------------| | | | Label Release | (Unicast) |------------------------------>| | Label Mapping | | (new label) | (Unicast) |<------------------------------| | Label Mapping | | (Label = K) | (Multicast) |<------------------------------| 5. Some Advice It is possible to interrupt unicast traffic when unicast assigns one new label after giving up the collided label. In order to avoid the traffic interrupt, unicast should assign one new label before giving up the old label. Maybe there need some other extensions for current mechanism, we maybe discuss more details in the latter version. Huang Expires December 16, 2006 [Page 5] Internet-Draft draft-huang-lable-collision-00.txt June 2006 6. IANA Considerations This document will propose some minor extensions to LDP that may require the allocation of new code points under the care of IANA. A future version of this document will include the relevant information. 7. References 7.1. Normative References [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification", RFC3036, January 2001. 7.2. Informative References [OVER] Seisho Yasukawa, Adrian Farrel, "Support of LDP Multicast Label Switched Paths over Point-to-Multipoint Label Switched Path Tunnels and on Multi-Access Links", draft- yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01.txt, Work in progress. [UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", draft-ietf- mpls-upstream-label-00.txt, Work In Progress. 8. Author's Addresses Zheng Huang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: szhuangzheng@huawei.com Yang Yang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: healthinghearts@huawei.com 9. 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 Huang Expires December 16, 2006 [Page 6] Internet-Draft draft-huang-lable-collision-00.txt June 2006 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Huang Expires December 16, 2006 [Page 7]