idnits 2.17.1 draft-blake-aris-lan-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. ** The abstract seems to contain references ([ARIS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 172: '...C implementation SHOULD be capable of ...' RFC 2119 keyword, line 176: '... The LMFC MUST permit the precise sp...' RFC 2119 keyword, line 182: '... The LMFC MUST NOT flood frames with...' RFC 2119 keyword, line 185: '...MISRs. The LMFC SHOULD support the ab...' RFC 2119 keyword, line 188: '... SHOULD support the ability to drop ...' 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 (March 1997) is 9904 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ARIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TAG' -- Possible downref: Non-RFC (?) normative reference: ref. 'FANP' -- Possible downref: Non-RFC (?) normative reference: ref. 'LABEL' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASPEC' ** Obsolete normative reference: RFC 1972 (Obsoleted by RFC 2464) ** Obsolete normative reference: RFC 2019 (Obsoleted by RFC 2467) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Steven Blake 3 Expiration Date: September 1997 Anoop Ghanwani 4 Wayne Pace 5 Vijay Srinivasan 7 IBM Corporation 9 March 1997 11 ARIS Support for LAN Media Switching 13 15 Status of This Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 ARIS (Aggregate Route-based IP Switching) [ARIS] is a protocol which, 36 in coordination with network-layer routing protocols, establishes 37 link-layer switched paths through a network of Integrated Switch 38 Routers (ISR). This memo describes ARIS protocol mechanisms which 39 enable LAN media switching of IP packets. In addition, this memo 40 describes the functional behavior of ISRs which are interconnected 41 via LAN media (e.g., ethernet, token ring, FDDI). The proposed 42 mechanisms are designed to permit easy implementation using emerging 43 LAN switching technology. 45 1. Applicability Statement 47 Several proposals that deal with improving the performance of IP 48 forwarding by carrying labels in the packets have recently been 49 submitted to the MPLS working group [ARIS, TAG, FANP]. The labels 50 are used for indexing tables which enable fast IP forwarding at close 51 to media speeds by minimizing the need for network-layer packet 52 processing. The labels may be carried in different ways depending on 53 the underlying link-layer technology. For instance, in ATM networks, 54 the label may be represented by a particular VPI/VCI value. Since 55 ATM is a label swapping technology, it is possible for label 56 allocation to be a local choice for each node participating in the 57 protocol. This is not possible for LAN switching technologies such 58 as ethernet, token ring, and FDDI, which are not inherently label 59 swapping technologies. As a consequence, a shim consisting of one or 60 more 32-bit label stack entries inserted between the link-layer and 61 the network-layer headers has been proposed as a means to convey the 62 label information [LABEL]. The main drawback of using such an 63 approach is that accessing the labels requires that the frames be 64 processed by software, reducing the benefit offered by label 65 switching. Alternatively, hardware technology specific to label 66 switching may be developed. However, devices incorporating this 67 technology are likely to be more expensive that traditional LAN 68 switches and bridges. 70 This memo proposes a different approach for label switching on LAN 71 media which uses the ARIS protocol for distribution of labels. The 72 label is carried in the destination address portion of the frame and, 73 for unicast, is usually the MAC address of the egress point from the 74 network as identified by ARIS. With this approach, an implementation 75 using emerging bridge/switch hardware capable of supporting the IEEE 76 802.1p forwarding and filtering rules is possible [802.1P]. However, 77 the labels must now have global significance and are required to be 78 unique. The focus of this memo is to describe a label distribution 79 and switching mechanism which can be applied among ISRs which are 80 interconnected via point-to-point LAN media links. Such a mechanism 81 can provide significant benefit in the backbone of campus networks, 82 for example. 84 2. Introduction 86 An Integrated Switch Router (ISR) is a link-layer switch which has 87 been augmented with IP routing capability, in addition to the ARIS 88 protocol [ARIS]. Virtual circuits (VCs) which are established by 89 application of the ARIS protocol enable switching of IP packets 90 across a network of ISRs. Here the term "virtual circuit" is used 91 loosely to imply a switched path in any switching technology. 93 ARIS switched path establishment is coupled to IP routing by means of 94 the "egress identifier". An egress identifier may refer to an egress 95 ISR which forwards traffic either to a foreign routing domain, or 96 across an area boundary within the same network. Alternatively, an 97 egress identifier may refer to a particular (S,G) multicast pair. 98 ARIS supports a wide variety of egress identifier semantics, each 99 providing a different level of traffic aggregation. 101 In the unicast traffic case, ARIS establishes a switched path for 102 each egress identifier advertised by an ISR by forwarding an 103 Establish message to each of that ISR's upstream neighbors. After 104 ensuring that the downstream ISR is on the routed path associated 105 with the egress identifier, and that the switched path is loop-free, 106 the upstream ISRs continue to forward Establish messages further 107 upstream until they reach all ingress ISRs in the ARIS network. The 108 resulting switched path resembles a multipoint-to-point tree 109 terminating at the egress ISR. The direction of path establishment 110 is reversed for multicast traffic, and the resulting switched path 111 forms a point-to-multipoint tree. 113 Each ARIS switched path for an egress identifier is associated with 114 a unique VC between adjacent ISRs. ISRs typically will swap the 115 VPI/VCI field of a cell (ATM) or the DLCI of a frame (Frame Relay) 116 with a new label value before forwarding to a downstream ISR on the 117 switched path. This operation is commonly referred to as "label 118 swapping". ISRs can merge multiple inbound VCs of a switched path 119 onto a single outbound VC if the underlying hardware supports this 120 capability. This reduces VC consumption and affords greater network 121 scalability. 123 Unlike ATM and Frame Relay, traditional LAN switching technology is 124 not based on label swapping. LAN switches forward a LAN frame based 125 on the 6-byte destination IEEE MAC address (DA) encoded in the frame 126 header [802.1D]. LAN switching hardware typically is not capable of 127 swapping the DA in the frame prior to forwarding. This style of 128 forwarding is referred to here as "label switching". LAN switches 129 are only able to forward frames unambiguously if each (individual) DA 130 is associated with only one network end-point. This requirement does 131 not present a significant limitation on network scalability since the 132 DA field is large enough to represent 2^46 unique end-points. 134 ARIS supports LAN media switching by associating each egress 135 identifier with a 6-byte switching label which is unique among all 136 switching labels in use within the ARIS network. The switching label 137 is encoded in the DA field within a LAN frame. ISRs cache the 138 switching label corresponding to each switched path. ISRs can 139 unambiguously identify frames corresponding to any particular egress 140 identifier by the value of the frame's DA field and can forward them 141 directly at the link-layer along the appropriate switched path. This 142 enables packets to be switched at hardware speeds across an entire 143 network of ISRs. 145 Unless otherwise specified, the behavior of the ARIS protocol is 146 identical to that described in [ASPEC]. 148 3. Components for LAN Media Switching 150 In this memo, a LAN Media ISR (LMISR) refers to a network node which 151 incorporates a LAN Media Forwarding Component (LMFC) along with a 152 network-layer control and forwarding component (IPCC). The LMFC 153 performs label switching based on the 6-byte DA of a received frame. 154 Direct link-layer switching between diverse LAN media types (10/100/ 155 1000 ethernet, token ring, FDDI) is possible if supported by the 156 underlying hardware. LMISRs are intended to form the core of a 157 scalable, high-bandwidth campus or enterprise network. 159 Associated with each LMFC is a LAN Media Forwarding Information Base 160 (LMFIB). The LMFIB specifies the association of switching-labels 161 (DAs) to outgoing interface(s). This table is used to configure the 162 LMFC's filtering database to enable link-layer forwarding. In the 163 default configuration, the 802.1D Spanning Tree protocol is disabled, 164 and every active interface (visible to IP routing) is placed in the 165 forwarding state [802.1D]. 167 To permit IP control traffic to reach the IPCC within a LMISR, and to 168 permit network-layer forwarding of packets on a switched path which 169 has been broken downstream, the IPCC is associated with one or more 170 logical interfaces in the LMFIB. This allows the IPCC to redirect 171 packets on a pre-established switched path through the IPCC. 172 The IPCC implementation SHOULD be capable of simultaneously receiving 173 LAN frames with arbitrary DA values. Note that the LMFIB can be used 174 to filter the addresses which are received by the IPCC. 176 The LMFC MUST permit the precise specification of the output 177 interface(s) to be associated with each received DA (individual or 178 group address scope). This capability is consistent with the 179 Extended Filtering Mode and Port Filtering Mode C as described in 180 Section 2.6.6 of [802.1P]. 182 The LMFC MUST NOT flood frames with an unknown DA or with the 183 broadcast DA out of every LMFC interface in forwarding state. These 184 rules are necessary to prevent link-layer loops from forming amongst 185 adjacent LMISRs. The LMFC SHOULD support the ability to forward 186 frames with an unknown DA or with the broadcast DA to a particular 187 LMFC interface associated with the IPCC. In addition, the LMFC 188 SHOULD support the ability to drop frames with an unknown DA or with 189 the broadcast DA. 191 Existing LAN switch implementations typically do not support the 192 capability to swap the DA of a frame. ARIS does not require this 193 capability to function efficiently, but allows LMISRs whose LMFCs are 194 capable of DA swapping to alter the switching label associated with 195 an egress identifier when forwarding Establish messages upstream 196 towards an ingress ISR. It is the responsibility of such a LMISR to 197 select a unique 6-byte switching label when transmitting an Establish 198 message for the associated egress identifier, and to perform the 199 correct DA swapping operation to/from the initial DA value when 200 forwarding frames. 202 4. LAN Media Frame Encapsulation 204 ARIS support for LAN media switching does not require a new 205 encapsulation format for IP packets. IPv4 and IPv6 packets should be 206 encapsulated according to the appropriate RFC specification for each 207 LAN media [RFC1042, RFC1972, RFC2019]. This includes the default 208 value of the maximum transmission unit (MTU) for each LAN media link. 210 5. IP Multicast Support 212 As described in [ARIS], the establishment of point-to-multipoint 213 switched paths for IP multicast traffic is initiated at the root 214 (ingress) node. The switched path tree forwards traffic from the 215 ingress ISR to all egress ISRs on the multicast tree by using 216 multicast switching at the intermediate ISRs. 218 The ingress LMISR for a multicast switched path tree forwards an 219 Establish message containing the switching label for the associated 220 egress identifier to its downstream LMISRs. The Establish message 221 traverses from the ingress node to the downstream LMISRs in reverse 222 path multicast (RPM) style. The branches of the point-to-multipoint 223 tree that do not lead to receivers are pruned when the multicast 224 routing protocol prunes up by deleting forwarding entries in the 225 LMFIB. The ingress LMISR periodically refreshes the multicast 226 switched path tree by retransmitting an Establish message containing 227 the switching label for the associated egress identifier. 229 6. Multipath Support 231 As described in Section 2, a single switching label is associated 232 with an egress identifier in the default configuration. In this 233 case, a LMISR which has received multiple Establish messages for an 234 egress identifier, each associated with an equal-cost path to the 235 corresponding egress LMISR, cannot forward multiple Establish 236 messages with the same switching label to each of its upstream 237 LMISRs, since this will not allow the upstream LMISRs to distinguish 238 the multiple equal-cost paths. 240 An LMISR which wishes to utilize multiple equal-cost paths to an 241 egress has the following alternatives: 243 o Forward only one Establish message for an egress identifier to 244 each upstream LMISR, and forward traffic on that switched path 245 at the IP layer, 247 o Forward multiple Establish messages for an egress identifier to 248 each upstream LMISR, where each Establish message contains a 249 distinct switching label (all but one of which must be generated 250 dynamically by the LMISR). The LMISR must be capable of DA 251 swapping between the dynamically generated label(s) and the 252 original label selected by the egress LMISR. 254 7. Explicit Route Support 256 Explicit routes for point-to-point, point-to-multipoint, and 257 multipoint-to-point forwarding are established as described in 258 [ARIS]. In the case of point-to-point explicit routes, either the 259 ingress or the egress may initiate the path establishment, and may 260 select the switching label. In the case of multipoint-to-point 261 explicit routes, the egress initiates the switched path establishment 262 and selects the switching label. In the case of point-to-multipoint 263 explicit routes, the ingress initiates the switched path 264 establishment and selects the switching label. 266 8. Security Considerations 268 An analysis of security considerations will be provided in a future 269 revision of this memo. 271 9. Intellectual Property Considerations 273 International Business Machines Corporation may seek patent or other 274 intellectual property protection for some or all of the aspects 275 discussed in the forgoing document. 277 10. Acknowledgements 279 The authors wish to acknowledge the following individuals for their 280 input and assistance: Rick Boivie, Ed Bowen, Brian Carpenter, Allen 281 Carriker, Gene Cox, Ed Ellesson, Jim Ervin, Nancy Feldman, John 282 Linville, Sanjeev Rampal, Norm Strole, Arun Viswanathan, and Jeff 283 Warren. 285 11. References 287 [ARIS] A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, 288 "ARIS: Aggregate Route-Based IP Switching", Internet Draft 289 , March 1997. 291 [TAG] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D. 292 Farinacci, "Tag Switching Architecture - Overview", 293 Internet Draft , 294 January 1997. 296 [FANP] K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, 297 T. Jinmei, H. Esaki, "Flow Attribute Notification Protocol 298 (FANP) Specification", Internet Draft 299 , February 1997. 301 [LABEL] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, 302 "Label Switching: Label Stack Encodings", Internet Draft 303 , March 1997. 305 [802.1P] "P802.1p Standard for Local and Metropolitan Area Networks- 306 Supplement to Media Access Control (MAC) Bridges: Traffic 307 Class Expediting and Dynamic Multicast Filtering", P802.1p/ 308 D5, LAN MAN Standards Committee, IEEE Computer Society, 309 February 1997. 311 [802.1D] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". 313 [ASPEC] N. Feldman, A. Viswanathan, "ARIS Specification", Internet 314 Draft , March 1997. 316 [RFC1042] J. Postel, J. Reynolds, "A Standard for the Transmission of 317 IP Datagrams over IEEE 802 Networks, Internet RFC 1042, 318 February 1988. 320 [RFC1972] M. Crawford, "A Method for the Transmission of IPv6 Packets 321 over Ethernet Networks", Internet RFC 1972, August 1996. 323 [RFC2019] M. Crawford, "A Method for the Transmission of IPv6 Packets 324 over FDDI Networks", Internet RFC 2019, October 1996. 326 12. Authors' Addresses 328 Steven Blake 329 IBM Corporation 330 P.O. Box 12195 331 Research Triangle Park, NC 27709 332 Phone: +1-919-254-2030 333 Fax: +1-919-254-5483 334 E-mail: slblake@vnet.ibm.com 336 Anoop Ghanwani 337 IBM Corporation 338 P.O. Box 12195 339 Research Triangle Park, NC 27709 340 Phone: +1-919-254-0260 341 Fax: +1-919-254-5410 342 E-mail: anoop@raleigh.ibm.com 344 Wayne Pace 345 IBM Corporation 346 P.O. Box 12195 347 Research Triangle Park, NC 27709 348 Phone: +1-919-254-4930 349 Fax: +1-919-254-5410 350 E-mail: pacew@raleigh.ibm.com 352 Vijay Srinivasan 353 IBM Corporation 354 P.O. Box 12195 355 Research Triangle Park, NC 27709 356 Phone: +1-919-254-2730 357 Fax: +1-919-254-5410 358 E-mail: vijay@raleigh.ibm.com