Internet Draft Internet-Draft Steven Blake Expiration Date: September 1997 Anoop Ghanwani Wayne Pace Vijay Srinivasan IBM Corporation March 1997 ARIS Support for LAN Media Switching <draft-blake-aris-lan-00.txt> Status of This Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract ARIS (Aggregate Route-based IP Switching) [ARIS] is a protocol which, in coordination with network-layer routing protocols, establishes link-layer switched paths through a network of Integrated Switch Routers (ISR). This memo describes ARIS protocol mechanisms which enable LAN media switching of IP packets. In addition, this memo describes the functional behavior of ISRs which are interconnected via LAN media (e.g., ethernet, token ring, FDDI). The proposed mechanisms are designed to permit easy implementation using emerging LAN switching technology. Blake, et al. Expires: September 1997 [Page 1] Internet-Draft ARIS Support for LAN Media Switching March 1997 1. Applicability Statement Several proposals that deal with improving the performance of IP forwarding by carrying labels in the packets have recently been submitted to the MPLS working group [ARIS, TAG, FANP]. The labels are used for indexing tables which enable fast IP forwarding at close to media speeds by minimizing the need for network-layer packet processing. The labels may be carried in different ways depending on the underlying link-layer technology. For instance, in ATM networks, the label may be represented by a particular VPI/VCI value. Since ATM is a label swapping technology, it is possible for label allocation to be a local choice for each node participating in the protocol. This is not possible for LAN switching technologies such as ethernet, token ring, and FDDI, which are not inherently label swapping technologies. As a consequence, a shim consisting of one or more 32-bit label stack entries inserted between the link-layer and the network-layer headers has been proposed as a means to convey the label information [LABEL]. The main drawback of using such an approach is that accessing the labels requires that the frames be processed by software, reducing the benefit offered by label switching. Alternatively, hardware technology specific to label switching may be developed. However, devices incorporating this technology are likely to be more expensive that traditional LAN switches and bridges. This memo proposes a different approach for label switching on LAN media which uses the ARIS protocol for distribution of labels. The label is carried in the destination address portion of the frame and, for unicast, is usually the MAC address of the egress point from the network as identified by ARIS. With this approach, an implementation using emerging bridge/switch hardware capable of supporting the IEEE 802.1p forwarding and filtering rules is possible [802.1P]. However, the labels must now have global significance and are required to be unique. The focus of this memo is to describe a label distribution and switching mechanism which can be applied among ISRs which are interconnected via point-to-point LAN media links. Such a mechanism can provide significant benefit in the backbone of campus networks, for example. 2. Introduction An Integrated Switch Router (ISR) is a link-layer switch which has been augmented with IP routing capability, in addition to the ARIS protocol [ARIS]. Virtual circuits (VCs) which are established by application of the ARIS protocol enable switching of IP packets across a network of ISRs. Here the term "virtual circuit" is used loosely to imply a switched path in any switching technology. ARIS switched path establishment is coupled to IP routing by means of the "egress identifier". An egress identifier may refer to an egress Blake, et al. Expires: September 1997 [Page 2] Internet-Draft ARIS Support for LAN Media Switching March 1997 ISR which forwards traffic either to a foreign routing domain, or across an area boundary within the same network. Alternatively, an egress identifier may refer to a particular (S,G) multicast pair. ARIS supports a wide variety of egress identifier semantics, each providing a different level of traffic aggregation. In the unicast traffic case, ARIS establishes a switched path for each egress identifier advertised by an ISR by forwarding an Establish message to each of that ISR's upstream neighbors. After ensuring that the downstream ISR is on the routed path associated with the egress identifier, and that the switched path is loop-free, the upstream ISRs continue to forward Establish messages further upstream until they reach all ingress ISRs in the ARIS network. The resulting switched path resembles a multipoint-to-point tree terminating at the egress ISR. The direction of path establishment is reversed for multicast traffic, and the resulting switched path forms a point-to-multipoint tree. Each ARIS switched path for an egress identifier is associated with a unique VC between adjacent ISRs. ISRs typically will swap the VPI/VCI field of a cell (ATM) or the DLCI of a frame (Frame Relay) with a new label value before forwarding to a downstream ISR on the switched path. This operation is commonly referred to as "label swapping". ISRs can merge multiple inbound VCs of a switched path onto a single outbound VC if the underlying hardware supports this capability. This reduces VC consumption and affords greater network scalability. Unlike ATM and Frame Relay, traditional LAN switching technology is not based on label swapping. LAN switches forward a LAN frame based on the 6-byte destination IEEE MAC address (DA) encoded in the frame header [802.1D]. LAN switching hardware typically is not capable of swapping the DA in the frame prior to forwarding. This style of forwarding is referred to here as "label switching". LAN switches are only able to forward frames unambiguously if each (individual) DA is associated with only one network end-point. This requirement does not present a significant limitation on network scalability since the DA field is large enough to represent 2^46 unique end-points. ARIS supports LAN media switching by associating each egress identifier with a 6-byte switching label which is unique among all switching labels in use within the ARIS network. The switching label is encoded in the DA field within a LAN frame. ISRs cache the switching label corresponding to each switched path. ISRs can unambiguously identify frames corresponding to any particular egress identifier by the value of the frame's DA field and can forward them directly at the link-layer along the appropriate switched path. This enables packets to be switched at hardware speeds across an entire network of ISRs. Unless otherwise specified, the behavior of the ARIS protocol is Blake, et al. Expires: September 1997 [Page 3] Internet-Draft ARIS Support for LAN Media Switching March 1997 identical to that described in [ASPEC]. 3. Components for LAN Media Switching In this memo, a LAN Media ISR (LMISR) refers to a network node which incorporates a LAN Media Forwarding Component (LMFC) along with a network-layer control and forwarding component (IPCC). The LMFC performs label switching based on the 6-byte DA of a received frame. Direct link-layer switching between diverse LAN media types (10/100/ 1000 ethernet, token ring, FDDI) is possible if supported by the underlying hardware. LMISRs are intended to form the core of a scalable, high-bandwidth campus or enterprise network. Associated with each LMFC is a LAN Media Forwarding Information Base (LMFIB). The LMFIB specifies the association of switching-labels (DAs) to outgoing interface(s). This table is used to configure the LMFC's filtering database to enable link-layer forwarding. In the default configuration, the 802.1D Spanning Tree protocol is disabled, and every active interface (visible to IP routing) is placed in the forwarding state [802.1D]. To permit IP control traffic to reach the IPCC within a LMISR, and to permit network-layer forwarding of packets on a switched path which has been broken downstream, the IPCC is associated with one or more logical interfaces in the LMFIB. This allows the IPCC to redirect packets on a pre-established switched path through the IPCC. The IPCC implementation SHOULD be capable of simultaneously receiving LAN frames with arbitrary DA values. Note that the LMFIB can be used to filter the addresses which are received by the IPCC. The LMFC MUST permit the precise specification of the output interface(s) to be associated with each received DA (individual or group address scope). This capability is consistent with the Extended Filtering Mode and Port Filtering Mode C as described in Section 2.6.6 of [802.1P]. The LMFC MUST NOT flood frames with an unknown DA or with the broadcast DA out of every LMFC interface in forwarding state. These rules are necessary to prevent link-layer loops from forming amongst adjacent LMISRs. The LMFC SHOULD support the ability to forward frames with an unknown DA or with the broadcast DA to a particular LMFC interface associated with the IPCC. In addition, the LMFC SHOULD support the ability to drop frames with an unknown DA or with the broadcast DA. Existing LAN switch implementations typically do not support the capability to swap the DA of a frame. ARIS does not require this capability to function efficiently, but allows LMISRs whose LMFCs are capable of DA swapping to alter the switching label associated with an egress identifier when forwarding Establish messages upstream Blake, et al. Expires: September 1997 [Page 4] Internet-Draft ARIS Support for LAN Media Switching March 1997 towards an ingress ISR. It is the responsibility of such a LMISR to select a unique 6-byte switching label when transmitting an Establish message for the associated egress identifier, and to perform the correct DA swapping operation to/from the initial DA value when forwarding frames. 4. LAN Media Frame Encapsulation ARIS support for LAN media switching does not require a new encapsulation format for IP packets. IPv4 and IPv6 packets should be encapsulated according to the appropriate RFC specification for each LAN media [RFC1042, RFC1972, RFC2019]. This includes the default value of the maximum transmission unit (MTU) for each LAN media link. 5. IP Multicast Support As described in [ARIS], the establishment of point-to-multipoint switched paths for IP multicast traffic is initiated at the root (ingress) node. The switched path tree forwards traffic from the ingress ISR to all egress ISRs on the multicast tree by using multicast switching at the intermediate ISRs. The ingress LMISR for a multicast switched path tree forwards an Establish message containing the switching label for the associated egress identifier to its downstream LMISRs. The Establish message traverses from the ingress node to the downstream LMISRs in reverse path multicast (RPM) style. The branches of the point-to-multipoint tree that do not lead to receivers are pruned when the multicast routing protocol prunes up by deleting forwarding entries in the LMFIB. The ingress LMISR periodically refreshes the multicast switched path tree by retransmitting an Establish message containing the switching label for the associated egress identifier. 6. Multipath Support As described in Section 2, a single switching label is associated with an egress identifier in the default configuration. In this case, a LMISR which has received multiple Establish messages for an egress identifier, each associated with an equal-cost path to the corresponding egress LMISR, cannot forward multiple Establish messages with the same switching label to each of its upstream LMISRs, since this will not allow the upstream LMISRs to distinguish the multiple equal-cost paths. An LMISR which wishes to utilize multiple equal-cost paths to an egress has the following alternatives: o Forward only one Establish message for an egress identifier to Blake, et al. Expires: September 1997 [Page 5] Internet-Draft ARIS Support for LAN Media Switching March 1997 each upstream LMISR, and forward traffic on that switched path at the IP layer, o Forward multiple Establish messages for an egress identifier to each upstream LMISR, where each Establish message contains a distinct switching label (all but one of which must be generated dynamically by the LMISR). The LMISR must be capable of DA swapping between the dynamically generated label(s) and the original label selected by the egress LMISR. 7. Explicit Route Support Explicit routes for point-to-point, point-to-multipoint, and multipoint-to-point forwarding are established as described in [ARIS]. In the case of point-to-point explicit routes, either the ingress or the egress may initiate the path establishment, and may select the switching label. In the case of multipoint-to-point explicit routes, the egress initiates the switched path establishment and selects the switching label. In the case of point-to-multipoint explicit routes, the ingress initiates the switched path establishment and selects the switching label. 8. Security Considerations An analysis of security considerations will be provided in a future revision of this memo. 9. Intellectual Property Considerations International Business Machines Corporation may seek patent or other intellectual property protection for some or all of the aspects discussed in the forgoing document. 10. Acknowledgements The authors wish to acknowledge the following individuals for their input and assistance: Rick Boivie, Ed Bowen, Brian Carpenter, Allen Carriker, Gene Cox, Ed Ellesson, Jim Ervin, Nancy Feldman, John Linville, Sanjeev Rampal, Norm Strole, Arun Viswanathan, and Jeff Warren. 11. References [ARIS] A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, "ARIS: Aggregate Route-Based IP Switching", Internet Draft <draft-viswanathan-aris-overview-00.txt>, March 1997. Blake, et al. Expires: September 1997 [Page 6] Internet-Draft ARIS Support for LAN Media Switching March 1997 [TAG] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D. Farinacci, "Tag Switching Architecture - Overview", Internet Draft <draft-rekhter-tagswitch-arch-00.txt>, January 1997. [FANP] K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki, "Flow Attribute Notification Protocol (FANP) Specification", Internet Draft <draft-rfced-info-nagami-00.txt>, February 1997. [LABEL] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, "Label Switching: Label Stack Encodings", Internet Draft <draft-rosen-tag-stack-01.txt>, March 1997. [802.1P] "P802.1p Standard for Local and Metropolitan Area Networks- Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting and Dynamic Multicast Filtering", P802.1p/ D5, LAN MAN Standards Committee, IEEE Computer Society, February 1997. [802.1D] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". [ASPEC] N. Feldman, A. Viswanathan, "ARIS Specification", Internet Draft <draft-feldman-aris-spec-00.txt>, March 1997. [RFC1042] J. Postel, J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks, Internet RFC 1042, February 1988. [RFC1972] M. Crawford, "A Method for the Transmission of IPv6 Packets over Ethernet Networks", Internet RFC 1972, August 1996. [RFC2019] M. Crawford, "A Method for the Transmission of IPv6 Packets over FDDI Networks", Internet RFC 2019, October 1996. 12. Authors' Addresses Steven Blake IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-2030 Fax: +1-919-254-5483 E-mail: slblake@vnet.ibm.com Anoop Ghanwani IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-0260 Blake, et al. Expires: September 1997 [Page 7] Internet-Draft ARIS Support for LAN Media Switching March 1997 Fax: +1-919-254-5410 E-mail: anoop@raleigh.ibm.com Wayne Pace IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-4930 Fax: +1-919-254-5410 E-mail: pacew@raleigh.ibm.com Vijay Srinivasan IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-2730 Fax: +1-919-254-5410 E-mail: vijay@raleigh.ibm.com Blake, et al. Expires: September 1997 [Page 8]