idnits 2.17.1 draft-farinacci-multicast-tag-part-00.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 (December 1996) is 9994 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 201, but no explicit reference was found in the text -- No information found for draft-rfced-tag-switching-overview - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 Internet Draft cisco Systems 4 Expiration Date: June 1997 December 1996 6 Partitioning Tag Space among Multicast Routers on a Common Subnet 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 There are 3 major functions that must be performed to achieve 30 multicast tagswitching. 1) Tag Allocation, which requires each 31 multicast Tag Switching Router (TSR) to have a tag value range that 32 it uses. 2) Tag Binding, using the tags allocated, a TSR must assign 33 them to multicast routes. 3) Tag Binding Distribution, after binding 34 tag values to routes, they must be distributed to other TSRs so they 35 all forward on a common and consistent distribution tree. 37 In this document we present how tags are allocated uniquely across 38 multicast capable TSRs on a LAN and point-to-point IP subnets. 40 1. Introduction 42 This memo specifies a simple algorithm to partition a tag allocation 43 space among multicast TSRs on a common media. So that each range 44 allocated to a router is unique and non overlapping with any range 45 allocated to any other TSR on that network media. 47 Since an upstream TSR will use a single tag for a multicast packet, 48 all downstream TSRs, on the same subnet as the upstream router, must 49 be ready to use it to do multicast tag forwarding. Therefore, no 50 other TSR, on the subnet, can use the same tag or it would be 51 ambiguous which multicast distribution tree to forward on. Therefore, 52 each TSR might be potentially an upstream TSR for different multicast 53 distribution trees and needs its own tag range. 55 This procedure can be used for any tag binding and distribution 56 scheme, be it upstream or downstream multicast tag distribution. 58 2. LAN Procedure 60 Each multicast TSR on a LAN is configured with the tag table size it 61 will use for the LAN interface. An approximate router-count will also 62 be configured. This allows a router to allocate a range equal to 63 1/router-count of the tag table size. This tag table is used for 64 multicast tag forwarding only. 66 When a multicast TSR boots up or enables the LAN interface to do 67 multicast routing, it will advertise in PIM Hello messages the tag 68 table size, router count and the tag range it randomly selects. The 69 lower range tag value and the higher range tag value accompany the 70 advertisement. A TSR verifies that no other TSR on the LAN is using 71 the tag range before it advertises the one it selected. 73 If there is another TSR that has selected the same range and it has a 74 higher IP address than the newly booted TSR, the other TSR will 75 trigger a PIM Hello message unicasted to that newly booted TSR 76 indicating that it owns that range. The newly booted TSR will then 77 select another range randomly. If the newly booted TSR has a higher 78 IP address than the other TSR, the other TSR will withdraw his tag 79 bindings and randomly allocate another tag range. Then it will 80 reallocate its bindings. 82 A TSR can be configured to use more than one tag range if one 83 believes it will be an upstream TSR for many flows. It just inserts 84 additional advertisements in the same PIM Hello message. The tag 85 table size and router-count should be the same in all advertisements 86 contained in a message. 88 3. Point-to-point Procedure 90 On point-to-point links since there can only be one forwarder from a 91 TSR's point of view (the other end of the link), each TSR can use the 92 entire tag table size as their tag range. There is no conflict 93 because there can be one and only one downstream neighbor for a given 94 distribution tree. 96 Also, the tag table size advertised in PIM Hello messages over 97 point-to-point links don't have to be the same size. The router-count 98 is ignored for point-to-point advertisements. 100 4. Configuration Errors 102 If the tag table size is not configured consistently on all TSRs 103 connected to a LAN, the smallest table size advertised by any TSR 104 will be used. 106 If the router-count is not configured consistently on all TSRs 107 connected to a LAN, the smallest router-count value advertised by any 108 TSR will be used. This means the largest division of the tag table 109 space will occur. 111 5. Subnet Partitioning 113 When a subnet partitions and new multicast TSRs come up, they will 114 allocate tag ranges that are unique to their partition. When the 115 partition heals, there may be conflicts. Once the PIM Hellos messages 116 are received by TSRs on the other side of the partition, they will 117 determine there is a tag range allocation conflict and immediately 118 perform the tie breaking rules described above. 120 6. Exceeding the Tag Table Size 122 When a TSR cannot allocate a tag range because all ranges within the 123 tag table size have been allocated, it will not participate in 124 binding tags to multicast routes. Packets for these routes will not 125 be tagswitched. However, the TSR is still capable of tagswitching a 126 packet as either an upstream or downstream TSR on that LAN. This is 127 the case when another router is binding tags for the multicast route 128 and has an allocated a tag range successfully. 130 7. PIM Hello Packet Format 132 The PIM Hello message will carry a new OptionType (called "Tag 133 Parameters") as specified in [2]. A router that sends a PIM Hello 134 with this option is regarded as being tag-capable. This Option can 135 appear multiple times in a Hello packet if a TSR wants to allocate 136 multiple ranges. When this option appears multiple times in the Hello 137 message, the Tag Table Size and Router Count must be the same for 138 each Tag Parameters Option supplied in the message. 140 When sent on point-to-point links, this option should have Router 141 Count, Lower Tag Range, and Upper Tag Range set to 0. These fields 142 are ignored on receipt. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | OptionType = 17 | OptionLength = 16 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Tag Table Size | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Router Count | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Lower Tag Range | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Upper Tag Range | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 OptionType "Tag Parameters" 159 Set to value 17 decimal. 161 OptionLength 162 The option is 16 bytes in length. 164 Tag Table Size 165 The size of the TIB, in number of entries, the sending router 166 supports on the interface the Hello is sent on. 168 Router Count 169 The approximate maximum number of routers that may be connected to 170 the subnet the Hello is sent on. 172 Lower Tag Range 173 The lower tag value in the tag range that was been randomly 174 selected by the sending router. This value must be less than the 175 Upper Tag Range value. 177 Upper Tag Range 178 The upper tag value in the tag range that was been randomly 179 selected by the sending router. This value must be greater than 180 the Lower Tag Range value. 182 8. Security Considerations 184 Security considerations are not discussed in this memo. 186 9. Acknowledgments 188 Contributions to this work has been made by Yakov Rekhter. 190 10. Author's Address: 192 Dino Farinacci 193 Cisco Systems, Inc. 194 170 Tasman Drive 195 San Jose, CA, 95134 197 Email: dino@cisco.com 199 11. References 201 [1] Tag Switching Architecture Overview, draft-rfced-tag-switching- 202 overview-00.txt, Rekhter, Davie, Katz, Rosen, Swallow 204 [2] Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol 205 Specification, , Estrin, 206 Farinacci, Helmy, Thaler, Deering, Handley, Jacobson, Liu, Sharma, 207 Wei, October, 1996