INTERNET-DRAFT A Framework for IP over RPR February 2001 Network Working Group Albert Herrera Internet Draft Russ White draft-ietf-iporpr-framework-00.txt Cisco Systems Expiration Date: August 2001 Pankaj K. Jha Cypress Semiconductor Raj Sharma Sanjay Agrawal Prasad Jogalekar Arun Sastry Luminous Networks Khaled Amer AmerNet February 2001 A Framework for IP over Resilient Packet Rings <draft-ietf-iporpr-framework-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Herrera, et al. Expires August 2001 [Page 1]
INTERNET-DRAFT A Framework for IP over RPR February 2001 Abstract This document discusses technical issues and requirements for the IP over Resilient Packet Rings working group. It is the intent of this document to produce a coherent description of all significant approaches, which were and are being considered by the working group. Selections of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. Specification of Requirements 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 Overview of IPoRPR....................................... 3 2 Requirements ........................................... 4 3 Motivation for IPoRPR .................................. 5 3.1 Benefits Related to Cost Metrics Awareness ............. 5 3.2 Benefits Related to Adjacency Awareness ................ 6 3.3 Benefits Related to TE/ER/QoS Routing Support .......... 6 4 Technical Approaches ................................... 7 4.1 Adjacency Creation and Associated Metrics .............. 7 4.2 Fault Interaction ...................................... 7 4.3 Traffic Engineering .................................... 8 5 Acknowledgements ....................................... 8 6 Security ............................................... 8 7 Full Copyright Statement ............................... 8 8 References ............................................. 9 9 Author's Addresses ..................................... 9 Herrera, et al. Expires August 2001 [Page 2]
INTERNET-DRAFT A Framework for IP over RPR February 2001 1. Overview of IPoRPR The primary goal of the IPoRPR Working Group is to standardize a base technology that integrates RPR (Resilient Packet Rings) MAC functions as defined by the IEEE 802.17 Working Group with network layer routing. IEEE 802.17 is expected to optimize packet transport over rings on LAN, MAN and WAN topologies. This document takes into consideration the parallel efforts that are progressing within both the IEEE and IETF. It is for this reason that only the most fundamental and basic features are considered for this framework document. The only 802.17 features that this document takes into account are the following: - Dual counter-rotating rings, both fully utilized for data and control traffic - Rings composed of physical, point-to-point spans creating a logical ring - Destination stripping of unicast packets where the packet is stripped from the ring by the receiving node - Some sort of Protection Switching No other 802.17 features are assumed other than the above. Traditional network layer routing will treat these rings as a broadcast capable LAN media similar to Ethernet. IPoRPR will enable additional Layer 3 intelligence to fully utilize these MAC features to improve efficiencies and scalability at the network layer Herrera, et al. Expires August 2001 [Page 3]
INTERNET-DRAFT A Framework for IP over RPR February 2001 2. Requirements The following are high-level requirements for L2-L3 interaction between 802.17 and layer 3 protocols. - L3 protocols MAY need the option to communicate administrative weights to 802.17. - L3 protocols MAY need to have the option to choose the ring direction. - L3 protocols MAY need to have knowledge of the fault occurrences within the ring - Traffic Engineering specifications MUST support MPLS-TE over 802.17. - L3 and MPLS QoS mappings MAY need to be communicated to 802.17 QoS mechanisms - IPoRPR MUST address a wide range of routing protocols. Considerable optimizations can be achieved in some cases by small enhancements to existing protocols. Such enhancements MAY be considered in the case of IETF standard routing protocols, and if appropriate, coordinated with the relevant working group(s). - IPoRPR MUST support operations, administration, and maintenance facilities that are at least as extensive as those supported in current IP networks. Current network management and diagnostic tools SHOULD continue to work in order to provide some backward compatibility. - The IPoRPR should scale across hierarchical networks. Herrera, et al. Expires August 2001 [Page 4]
INTERNET-DRAFT A Framework for IP over RPR February 2001 3. Motivation for IPoRPR The evolution of Metro access networks has driven the industry to establish the new IEEE 802.17 WG. This WG is expected to define a MAC layer that has to be integrated to the upper layer protocols. This integration will allow additional mechanisms and support for Traffic Engineering, routing, QoS and fast convergence. This section describes the expected benefits of IPoRPR. At the physical layer, 802.17 looks like a set of point-to-point spans while at the datalink layer it appears to be a broadcast media LAN (equivalent to Ethernet, for instance). While current link-state routing protocols provide various media access models, such as broadcast, point-to-point, and point-to multipoint, none of the existing models can fully exploit the benefits that 802.17 has to offer. IPoRPR will define a logical model that closely reflects the underlying physical model and in the process enable routing protocols to directly utilize features not available in other ring topologies. 3.1 Benefits Related to Cost Metrics Awareness There are benefits associated with synchronizing L2 and L3 routing cost metrics as per different policies. At the MAC layer, 802.17 may implement its own topology discovery mechanism within a single ring implementation. This may involve tracking source/destination MAC addresses and utilizing the different matrices, including number of hops, to determine the most efficient ring direction (inner or outer) for delivery of unicast packets. For instance, in the network depicted below, the cost from node A to node C would be 1 hop across the directly connected side of the ring, while it would be two hops through node B. /----(20)------A / | C (5) \ | \----(5)-------B However, using the costs of the links between the nodes as seen by layer 3 protocols (based on physical distance or some other link trait, for instance), the path through node B is shorter. Herrera, et al. Expires August 2001 [Page 5]
INTERNET-DRAFT A Framework for IP over RPR February 2001 In networks such as this, communicating layer 3 metrics to the MAC layer, and vise-versa, can optimize packet delivery--especially in topologies with dramatic differences in node distances and costs. 3.2 Benefits Related to Adjacency Awareness Traditional network layer implementations treat all nodes on a shared media LAN as directly adjacent. Given 802.17's destination stripping ability, and once fault notification is enabled between Layer 2 and 3, it would be beneficial for Layer 3 to be aware of directly adjacent neighbors for route re-calculation during fault situations. Within a single ring, the benefits of adjacency awareness might not be obvious since the underlying 802.17 mechanisms will self-heal, send flows efficiently around or away from faults, and maintain connectivity. However, to fully reflect the changed topology during faults, route recalculation is necessary especially when a mix of ring and mesh topologies is deployed by the user. This will allow a recalculation of paths based on established cost metrics and will allow Layer 3 to effectively take any change in bandwidth of the ring into account. Adjacency awareness is closely tied to the cost metrics interaction between L2 and L3. 3.3 Benefits Related to TE/Explicit Routing/QoS Routing Support 802.17 may have inherent abilities to re-route around faults. It can be exploited by TE protocols to route tunnels across these rings. Traffic Engineering on shared media LANs will only account for bandwidth on the ingress node of a particular TE tunnel flow. In the case of 802.17, each node will not be aware of reservations made by other nodes. To take full advantage of 802.17, TE must manage bandwidth on both inner and outer rings. Adjacency awareness will closely represent the logical topology and physical ring topology. This enables proper accounting at each node and allows for full Traffic Engineering capabilities within the ring. MPLS allows explicit routing using Label Switched Paths to ensure that any particular stream of data takes a preferred path. This preferred path could be the long-path around the ring towards a destination node. This same mechanism will enable QoS routing in which the route chosen for a particular stream is chosen in response to the QoS required. Herrera, et al. Expires August 2001 [Page 6]
INTERNET-DRAFT A Framework for IP over RPR February 2001 4. Technical Approaches Technical approaches for IPoRPR may have to address policy management, QoS, Traffic Engineering, L2/L3 fault interaction and L3 routing. Future contributions will address these mechanisms in detail with appropriate assumptions in conjunction with the evolving 802.17 specification. Given the work-in-progress nature of 802.17, individual contributions may have to address different assumptions. The following are technical approaches which MIGHT be considered. 4.1 Adjacency Creation and Associated Metrics IS-IS and OSPF require knowledge of all neighbors on a ring with the additional information of which neighbor is directly connected upstream and directly connected downstream. This will allow the link-state protocols to advertise two adjacencies (upstream and downstream) and two associated metrics per interface. This will ensure that the logical topology calculated follows the physical topology. Adjustments to the next hop calculation is also necessary so cut- through forwarding can still occur between neighbors within the same ring. The preferred flooding of LSPs/LSAs can either be via a LAN or a point-to-point flooding algorithm. 4.2 Fault Interaction During fault situations, nodes adjacent to the fault will perform route recomputation and advertise a single ring adjacency in their LSP. This recomputation has to be triggered by a fault notification from 802.17 since protection-switching features of 802.17 will still maintain connectivity to the previously adjacent node (via a long path around the ring). Adjustments to established cost metrics around the ring might have to be adjusted to compensate for the fault situation. This will open up alternate paths (i.e. other than on the same ring) for congested flows. Herrera, et al. Expires August 2001 [Page 7]
INTERNET-DRAFT A Framework for IP over RPR February 2001 4.3 Traffic Engineering Traffic Engineering has its own constraint based SPF computations (C-SPF). C-SPF will follow the established logical topology when setting up TE-Tunnels and given that the logical closely resembles the physical, admission control will be much easier. This also allows for easier computation of RSVP path when setting up a new tunnel. 5. Acknowledgments The ideas and text in this document have been collected from a number of sources and comments received. We would like to thank Alvaro Retana, Don Slice, Liem Nguyen, Jason Fan, Vinay Bannai for their inputs and ideas. 6. Security Security in a network using IPoRPR should be relatively similar to security in a normal IP network. The route filtering and packet filtering features are unchanged. 7. Full Copyright Statement "Copyright (C) The Internet Society. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into.รถ Herrera, et al. Expires August 2001 [Page 8]
INTERNET-DRAFT A Framework for IP over RPR February 2001 8. References [1] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)" [Also republished as RFC 1142] [2] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", R. W. Callon, Dec. 1990 [3] RFC 2178, "OSPF Version 2", J. Moy. July 1997 [4] RFC 3031, "Multiprotocol Label Switching Architecture", E. Rosen, A. Viswanathan, R. Callon, January 2001. [5] IEEE 802.17 RPR PAR and 5 Criteria, http://www.ieee802.org/17, November 2000. 9. Author's Addresses Albert Herrera Cisco Systems, Inc. 365 March Road, Kanata, ON K2K 2C9 Phone: 613-271-3635 Email: albherre@cisco.com Russ White Cisco Systems, Inc. 7025 Kit Creek Road Research Triangle Park, NC Phone: 919 392-3139 Email: ruwhite@cisco.com Pankaj K Jha Cypress Semiconductor 3901 N First Street San Jose, CA 95134 Phone: 408 432 7091 pkj@cypress.com Raj Sharma (raj) Sanjay Agrawal (sanjay) Prasad Jogalekar (prasad) Arun Sastry (arun@luminousnetworks.com) Luminous Networks 10460 Bubb Road Cupertino, CA 95014 Tel: 408-342-6400 Khaled Amer AmerNet Email: khaledamer@usa.net Herrera, et al. Expires August 2001 [Page 9]
