Internet Draft Network Working Group Albert Herrera Internet Draft Russ White draft-ietf-ipoptr-framework-00.txt Cisco Systems Expiration Date: June, 2001 Pankaj K. Jha Cypress Semiconductor Raj Sharma Sanjay Agrawal Prasad Jogalekar Arun Sastry Luminous Networks Khaled Amer AmerNet December, 2000 A Framework for IP over Packet Transport Rings <draft-ietf-ipoptr-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 June, 2001 [Page 1] INTERNET-DRAFT A Framework for IP over PTR November, 2000 1. Abstract This document discusses technical issues and requirements for the IP over Packet Transport 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. 2. 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 Nyueng, Jason Fan, Vinay Bannai for their inputs and ideas. 3. Introduction and Requirements 3.1 Overview of IPoPTR The primary goal of the IPoPTR 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. The IPoPTR working group expects to optimize packet transport over rings on LAN, MAN and WAN topologies. Current network layer routing treats these rings as a broadcast capable LAN media similar to Ethernet. IPoPTR will enable additional Layer 3 intelligence to fully utilize MAC features, such as destination stripping and protection switching, to improve efficiencies and scalability at the network layer 3.2 Requirements o L3 protocols MAY need the option to communicate administrative weights to RPR. o L3 protocols MAY need to have the option to choose the ring direction. o L3 protocols MAY need to have knowledge of the fault occurrences within the ring o Traffic Engineering specifications MUST support MPLS-TE over RPR. o L3 and MPLS QoS mappings MAY need to be communicated to RPR QoS Herrera, et al Expires June, 2001 [Page 2] INTERNET-DRAFT A Framework for IP over PTR November, 2000 mechanisms o IPoPTR 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). o IPoPTR 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. o The IPoPTR should scale across hierarchical networks. 3.3 Acronyms and Abbreviations LSP Label Switched Path LSR Label Switch Router NBMA Non-Broadcast Multiple Access network RPR Resilient Packet Rings (IEEE802.17) MPLS Multi-Protocol Label Switching 3.4 Motivation for IPoPTR The evolution of Metro access networks has driven the industry to develop a new IEEE WG called RPR. This defines a MAC layer that has to be integrated to the upper layer protocols. This allows additional mechanisms and support for Traffic Engineering, routing, QoS and fast protection switching. This section describes the expected benefits of IPoPTR. At the physical layer, RPR 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 broadcast, point-to-point, and point-to multipoint, none of the existing models can fully exploit the benefits RPR has to offer. IPoPTR 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. Herrera, et al Expires June, 2001 [Page 3] INTERNET-DRAFT A Framework for IP over PTR November, 2000 3.4.1 Benefits Related to Cost Metrics Awareness There are benefits associated with synchronizing L2 and L3 routing cost metrics as per different policies. RPR, at the MAC layer, implements its own topology discovery mechanism within a single ring implementation. This involves 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. In networks such as this, then, 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.4.2 Benefits Related to Adjacency Awareness Adjacency awareness is closely tied to the cost metrics interaction between L2 and L3. 3.4.3 Benefits Related to TE/Explicit Routing/QoS Routing Support RPR has inherent abilities to re-route around faults. It can be exploited by TE protocols to route tunnels across these rings. To take full advantage of RPR, TE must manage bandwidth on both the inner and outer ring. This enables proper accounting at each node and allows for full Traffic Engineering capabilities within the ring. MPLS allows explicit routing of 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. 4. Technical Approaches Technical approaches for IPoPTR 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 RPR specification. Given the work-in-progress nature of RPR, individual contributions may have to address different assumptions. Herrera, et al Expires June, 2001 [Page 4] INTERNET-DRAFT A Framework for IP over PTR November, 2000 5. Security Security in a network using IPoPTR should be relatively similar to security in a normal IP network. The route filtering and packet filtering features are unchanged. 6. 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._ 7. 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. "Multiprotocol Label Switching Architecture", E. Rosen, A. Viswanathan, R. Callon, work in progress, draft-ietf-mpls-arch- 06.txt, August 1999. 5. IEEE 802.17 RPR PAR and 5 Criteria, http://www.ieee802.org/17, November 2000. 8. Author's Addresses Herrera, et al Expires June, 2001 [Page 5] INTERNET-DRAFT A Framework for IP over PTR November, 2000 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 June, 2001 [Page 6]