idnits 2.17.1 draft-farinacci-multicast-tagsw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1998) is 9294 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 283, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 290, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 297, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-02 ** Obsolete normative reference: RFC 2362 (ref. '2') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-03 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dino Farinacci 2 Internet Draft Yakov Rekhter 3 Expires: April, 1999 cisco Systems 4 November 1998 6 Multicast Label Binding and Distribution using PIM 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes a method for advertising labels for multicast 30 flows. It strives to use downstream label assignment to be 31 consistent with unicast label distribution. This proposal is media- 32 type independent. Therefore, it works for multi-access/multicast 33 capable LANs, point-to-point links, and NBMA networks. 35 1.0 Overview 37 We propose to use PIM and combine the (*,G) and (S,G) join state with 38 label assignment and distribution. Labels and multicast routes will 39 be sent together in one message. 41 1.1 Goals 43 i. We are motivated to have the upstream Label Switch Router (LSR) 44 use one label for multicast data delivery on a network so we can make 45 use of data-link multicast delivery where available. 47 ii. We are motivated to use downstream label assignment to achieve: 49 o Simplicity and consistency with unicast label assignment. 51 o A per interface Label Information Base (LIB) that guarantees 52 unique label assignments on any interface. 54 o Consistent algorithms for label assignment and distribution 55 among different media types. 57 o Both routing table state and the label binding information 58 associated with the state are advertised together in a single 59 control message thus reducing race conditions. 61 o Avoid label reallocation or reassignment when there are RPF 62 changes (i.e. the multicast distribution tree takes different 63 shape). 65 o To improve utilization of label space by randomizing label 66 assignment among all downstream routers joining for a group. 68 iii. Works with dense-mode or sparse-mode operation. 70 2.0 Proposal 72 A LSR that supports multicast sends PIM Join messages on behalf of 73 hosts that join groups. It sends Joins messages to upstream 74 neighboring LSRs toward the RP for the shared-tree (*,G) or toward a 75 source for a source-tree (S,G). If the LSR creates the state for the 76 group, it will assign a label for the respective (*,G) or (S,G) 77 state. It includes the label in the Join message associated with the 78 multicast routing table entry. The entry is created in its LIB using 79 the label as its incoming label component. 81 The upstream LSR, when it receives the Join, will cache the new 82 multicast routing table state along with the label. An entry is 83 created in the LIB and the label is used as the outgoing component. 84 This label will be used by the upstream LSR to forward multicast data 85 packets. 87 Since PIM Join messages are multicast on a LAN, other downstream 88 LSRs, that are interested in the group, will hear the message and can 89 cache the binding of multicast routing table state and label state 90 together. Since the upstream LSR is going to forward data packets 91 using the advertised label, they must be ready to accept the data 92 packet with that advertised label. 94 The first downstream LSR that joins for a group, is the label 95 assigner (or called in other forums as the Label Allocation Server) 96 on a LAN for a multicast route. All other downstream LSRs that send 97 PIM Join messages will use the same label that the assigner selected. 98 A LSR that sends a PIM Join message with a label of 0 means that it 99 doesn't know the label for the associated multicast routing table 100 entry. When this occurs, the assigner can trigger a PIM Join message 101 making the label known. 103 This algorithm works on point-to-point links because there is only 104 one downstream LSR on the link which always becomes the label 105 assigner. 107 On NBMA networks, all PIM routers are known to each other through 108 pseudo-broadcast mechanisms provided by the data-link layer. However, 109 PIM Join messages are unicast to the upstream LSR. Therefore, other 110 downstream LSRs will not hear the label assigner's advertisement. To 111 overcome this issue, we have each downstream LSR become the label 112 assigner on NBMA networks. Since the upstream LSR is going to 113 pseudo-broadcast the data anyways it can supply a label for each 114 packet that goes to each respective downstream LSR. 116 2.1 Corner cases 118 Multiple downstream LSRs cannot assign the same label value for any 119 multicast route because they partition the label space into non- 120 overlapping ranges according to [4]. When a LSR is enabled on an 121 interface, it obtains a unique label range for the LAN. 123 When the label assigner leaves the group, the label that it assigned 124 still remains active. The next highest IP addressed downstream LSR 125 becomes the owner of that label and may change it if it sees fit. 126 However, it is not required to change it. All downstream LSRs can 127 continue to use the assignment in their Join messages. 129 If two systems both join for the first time (they do not have state), 130 at the same time and each choose a different label value, the highest 131 IP addressed downstream LSR's label will be used by the upstream LSR. 132 The lower addressed LSR will hear the higher addressed LSR's Join too 133 and will also use it's label. 135 If the label assigner crashes, the highest IP addressed downstream 136 LSR assigns a new label to the multicast routes, which were assigned 137 by the crashing LSR, and triggers a Join message so all other LSRs on 138 the LAN to use the new label. 140 When a LAN partitions due to a layer-2 switch failure, it follows the 141 same logic for the case when a LSR stops joining for a group. When 142 the partition heals, there may be an RPF neighbor change in one of 143 the partitions. When there is an RPF neighbor change and the 144 downstream routers trigger joins to their new RPF neighbor with a 145 different label assignment than the other partition is using, one of 146 two resolutions occur: 148 1) The LSR which is the allocator in the partition of the new RPF 149 neighbor will trigger a join if it has a higher IP address than 150 the allocator in the other region. The downstream routers in the 151 other partition use the new label assignment immediately. 153 2) If the LSR which is the allocator in the partition of the new 154 RPF neighbor has a lower IP address, all downstream routers and 155 the new RPF neighbor will switch to the label assigned by the 156 allocator in the other partition. 158 If an RPF change occurs (the topology changed so the upstream LSR is 159 different), the PIM protocol spec indicates that a PIM Join may be 160 triggered to get on the new distribution tree as soon as possible. In 161 this case, if the label assigner becomes the upstream LSR, then the 162 new highest IP addressed downstream LSR may become the label 163 assigner. It may change the label if it sees fit. Otherwise, the same 164 label is used. 166 3.0 Coexistence of Label-Capable and Label-Incapable multicast routers 168 An upstream router will know if all routers on a subnet are LSRs or 169 not. If there are any label incapable routers, the upstream router 170 will not label encapsulate multicast data packets. The PIM Hello 171 message will indicate if the router is label capable. The PIM Hello 172 message is sent by every multicast capable router. 174 If the upstream router detects any non-PIM neighbors on the subnet, 175 it will assume that they are label capable and will not label 176 encapsulate multicast data packets. 178 An optimization may be achieved, if the upstream router knows that 179 all downstream routers interested in the group are LSRs, it may label 180 encapsulate multicast data packets even though there are other label 181 incapable routers on the subnet. 183 Related to the above cases, if there is a group member on a LAN, co- 184 located with a multicast LSR, only a single packet will be forwarded. 186 It is the responsibility of the upstream router to decapsulate the 187 labeled packet and forward it on the LAN as an IP packet so the 188 member can receive it. The downstream routers may forward the IP 189 packet or label encapsulate it. 191 4.0 Label Conflict Resolution 193 The use of different data-link layer code-points (i.e. Ethertypes, 194 PPP protocol types) for unicast and multicast label switching allows 195 to disambiguate between labels associated with unicast routes versus 196 labels associated with multicast routes. Therefore, the assignment of 197 labels for unicast routes could be done completely independent from 198 the assignment of labels for multicast routes, without creating any 199 risk of ambiguity. For example, the same label value could be 200 allocated for a unicast route and for a multicast route. 202 5.0 Modifications to PIMv2 204 PIMv2 has a packet format for each address type it may support when 205 encoding both multicast and unicast addresses. We will define a new 206 address type called "Label Address" for unicast address encoding. The 207 label will accompany the source address in the Encoded Source Address 208 format as specified in [2]. The label value will be in a 32-bit 209 quantity following the source address. So, for example, an IPv4 Label 210 Address format would look like: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Rsrvd |S|W|R| Mask Len | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Source Address | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Label | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Current Multicast Route Timer | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Label 225 A 20-bit value assigned by the LSR sending the Join/Prune message. 226 The 20 bit value is inserted in the low-order 20-bits of this 32- 227 bit field. 229 Current Multicast Route Timer 230 The sender of a Join/Prune message inserts the current time left 231 before expiration for the multicast route table entry described by 232 the Source Address (either the (S,G) or (*,G) entry). This is 233 needed so all routers on a common multi-access subnet can time-out 234 the entry close to the same time without each other recreating the 235 state when the source goes inactive. 237 Refer to [2] for other field descriptions not specified here. 239 6.0 Label Distribution for dense-mode groups 241 In dense-mode PIM, there is no downstream Join message traveling 242 upstream to perform the binding of multicast routes with labels. 243 However, since we don't want a separate algorithm for dense-mode 244 groups, we extend this basic design for dense-mode PIM. 246 When a downstream LSR creates (S,G) state from the receipt of 1) 247 data, or 2) Join/Prune or Graft messages, it will start a periodic 248 timer to send Join messages with label assignment information 249 present. The messages look no different and are treated on receipt no 250 differently than in the sparse-mode case. 252 The periodic Join message will be multicast on the LAN with an 253 upstream target address of 0.0.0.0. All multicast LSRs on the LAN 254 must know the group operates in dense-mode. This is accomplished 255 using standard PIM mechanisms. 257 7.0 Security Considerations 259 Security considerations are not discussed in this memo. 261 8.0 Acknowledgments 263 The authors would like to thank Fred Baker and Eric Rosen from cisco 264 Systems for their insightful comments on this draft. 266 9.0 Author's Address 268 Dino Farinacci 269 Cisco Systems, Inc. 270 170 Tasman Drive 271 San Jose, CA, 95134 272 Email: dino@cisco.com 274 Yakov Rekhter 275 Cisco Systems, Inc. 277 170 Tasman Drive 278 San Jose, CA, 95134 279 Email: yakov@cisco.com 281 10.0 References 283 [1] Multiprotocol Label Switching Architecture, draft-ietf-mpls- 284 arch-02.txt, Rosen, Viswanathan, Callon, July, 1998. 286 [2] Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 287 Specification, RFC 2362, Estrin, Farinacci, Helmy, Thaler, Deering, 288 Handley, Jacobson, Liu, Sharma, Wei, June, 1998 290 [3] LDP Specification, , Andersson, 291 Doolan, Feldman, Fredette, Thomas, August, 1998 293 [4] Partitioning Label Space amoung Multicast Routers on a Common 294 Subnet, , Farinacci, 295 October, 1998 297 [5] "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-03.txt, 298 Rosen, Rekhter, Tappan, Fedorkow, Li, Conta, September, 1998