NSIS Working Group Junkyun Choi Internet Draft Younghun Yoo Document: draft-choi-metro-signaling-00.txt ICU Expires: December 2002 June 2002 Consideration of RSVP-TE Extension for Metro Network 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. Abstract This draft mentions the bandwidth reservation in Metro Network. At first, this lists the issues that should be generally checked for bandwidth reservation, and is intended to point out RSVP-TE for Metro Network. Moreover, this focuses on consideration issues to understand whether the existing RSVP-TE supports the demands for bandwidth reservation in Metro Network. Conventions used in this document 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. Choi, et al. Expires - December 2002 [Page 1] Consideration of RSVP-TE Extension for Metro Network Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Issues for Bandwidth Reservation...............................4 3.1 Path Establishment.........................................4 3.2 Signaling Parameters.......................................4 3.3 Granularity of bandwidth...................................5 3.4 Resilience.................................................5 3.5 Transparency for path traversal............................6 4. Consideration issues in Metro Network..........................6 4.1 Assumption.................................................6 4.2 Path Establishment.........................................6 4.3 Granularity................................................6 4.4 Resilience.................................................7 4.5 Transparency...............................................7 5. Conclusion.....................................................7 References........................................................8 Author's Addresses................................................8 1. Introduction Metropolitan Area Networks (MAN) have emerged as a key network build- out point. In recent years, the bandwidth in Local Area Networks (LAN) has increased rapidly, driven by the widespread adoption of Gigabit Ethernet, while bandwidth capacity in Wide Area Networks (WAN) have exploded. As a result, the new bottleneck is in the MAN, the traffic intersection of the LAN and WAN, i.e. the data traffic explosion is increasing at unprecedented rates throughout the world, nowhere more so than in the MAN. The advent of high-speed LANs, broadband consumer access, Application Service Providers, inexpensive video conferencing, Voice over IP, and other high bandwidth applications and services has put tremendous pressure on metro network infrastructures. Therefore the bandwidth in the MAN will have to be provided in order to control network-based connection. The section for bandwidth reservation can be edge-to-edge or end-to- end. But we assume that the edge-to-edge bandwidth reservation method can be chosen for the MAN, which is explained in the Figure 1. +------+ +------+ | User |--+ +--| User | +------+ | | +------+ +------+ +------+ +------+ |Metro | |Core | |Metro | Choi, et al. Expires - January 2003 [Page 2] Consideration of RSVP-TE Extension for Metro Network |Switch| |Router| |Switch| +------+ +------+ +------+ / | \ / | \ / | \ / | \ / | \ / | \ +------+ | +------+ +------+ | +------+ +------+ | +------+ |Metro |--+--|Metro |---|Core |--+--|Core |---|Metro |--+--|Metro | |Switch| | |Switch| |Router| | |Router| |Switch| | |Switch| +------+ | +------+ +------+ | +------+ +------+ | +------+ \ | / \ | / \ | / \ | / \ | / \ | / +------+ +------+ +------+ |Metro | |core | |Metro | |Switch| |Router| |Switch| +------+ +------+ +------+ | | | | |<------------------->|<--------------------->|<------------------->| | MAN | WAN | MAN | | | +--------> Bandwidth Reservation <--------+ for Metro Edge-to-Metro Edge (using RSVP-TE) Figure 1: Bandwidth Reservation for MAN 2. Terminology Agent: any entity that takes part in QoS signaling. Domain: a collection of networks under the same administrative control and grouped for administrative purposes. End-to-End QoS: the QoS delivered by the network between two communicating end hosts. End-to-End QoS co-ordinates and enforces predefined traffic management policies across multiple network entities and administrative domains. Edge-to-Edge QoS: QoS within an administrative domain that connects to other networks rather than hosts or end systems. Flow: a traffic stream (sequence of IP packets between two end systems) for a specific level of QoS is to be provided. The flow can be unicast or multicast. Path: the route across the networks taken by a flow or aggregate, i.e. which domains/subdomains it passes through and the egress/ingress points for each. Path segment: the segment of a path within a single domain/subdomain. Choi, et al. Expires - January 2003 [Page 3] Consideration of RSVP-TE Extension for Metro Network QoS Controller: this is responsible for interpreting the signaling carrying the user QoS parameters, optionally inserting/modifying the parameters according to local network QoS management policy, and invoking local QoS provisioning mechanisms. QoS initiator: this is responsible for generating the QSCs for traffic flow(s) based on user or application requirements and signaling them to the network as well as invoking local QoS provisioning mechanisms. This can be located in the end system, but may reside elsewhere in network. QoS Service Classes (QSC): specify the QoS requirement of a traffic flow or aggregate. QoS Signaling: a way to communicate QSCs and QoS management information between hosts, end systems and network devices etc. May include request and response messages to facilitate negotiation/renegotiation, asynchronous feedback messages to inform End Hosts, QoS initiators and QoS controllers about current QoS levels, and QoS querying facilities. 3. Issues for Bandwidth Reservation This section lists the issues that should be generally checked for bandwidth reservation. 3.1 Path Establishment Before the signaling protocol supports the actual communication of QoS requirement information for traffic flows, the path from a source to a destination should be established. In order to support this, some actions must be carried out. - Peer Agent Discovery: The Agents should be able to discover peer Agents, and optionally establish a trust relationship with them. One Agent may discover one or more peer Agents in a number of different domains. Routing protocol and address resolution protocol are the typical methods for this. - Agent Selection: Each Agent selects the next hop Agent from the peers with which it has established a relationship during peer agent discovery. 3.2 Signaling Parameters The capabilities and the resource availabilities of the nodes along the data path are determined. Therefore the actual request for Choi, et al. Expires - January 2003 [Page 4] Consideration of RSVP-TE Extension for Metro Network resources that triggers the QoS provisioning must be passed through the nodes with QoS parameters. End-to-end different parameters may have relevance in different parts of the network. - Session ID to identify the traffic flow - Reservation ID to identify the reservation independently from the flow identifier - Initiator ID to identify the requestor of the reservation. +----------+ +----------+ +--------+ |+--------+| +--------+ |+--------+| +--------+ | Peer | || QoS || | QoS | || QoS || | Peer | | QoS |-->|| Cont- ||-->| Cont- |-->|| Cont- ||-->| QoS | | Cont- |<--|| roller ||<--| roller |<--|| roller ||<--| Cont- | | roller | || || | | || || | roller | +--------+ |+--------+| +--------+ |+--------+| +--------+ | Agent | | Agent | +----------+ +----------+ |<-----------Signaling Domain----------->| Figure 2: Signaling Domain with QoS Parameters 3.3 Granularity of bandwidth Aggregation of per-flow signaling is a technique contributing to scalability of bandwidth reservation. However depending on the network environments, such as Access Network, Metro Network and Backbone Network, diverse granularity of bandwidth should be able to be provisioned. For example, in the case of bandwidth insufficiency or small data traffic in network, bandwidth should be provided as much as needed. 3.4 Resilience If QoS control components are located within the data path, when a node fails or the data path changes due to re-routing both the signaling and data paths are affected. Resilience can be achieved by redirection around the point of failure. However, any state information maintained by the failed node must be transferred to another node, or re-discovered. If the QoS enabled path, including the state information can be re-established in a considerably short time an application would experience service degradation only for a short time period. Choi, et al. Expires - January 2003 [Page 5] Consideration of RSVP-TE Extension for Metro Network 3.5 Transparency for path traversal It should be possible for signaling to traverse path segments transparently, i.e. without interpretation by some QoS controllers. This ability can be useful when a local QoS provisioning protocol is employed in a subdomain. There is no need for signaling to be interpreted in this region. It is also useful for tunneling QoS signaling. When the signaling enters the transparent region, the adjacent controller would choose the next QoS controller beyond the transparent region as a next-hop QoS controller. 4. Consideration issues in Metro Network This draft suggests RSVP-TE, Extension to RSVP, in order to support bandwidth reservation in Metro Network, and this section mentions some consideration issues to adopt RSVP-TE as bandwidth reservation protocol in Metro Network. 4.1 Assumption The Agents in Metro Network consist of Metro Switches, which use RSVP-TE as bandwidth reservation protocol. 4.2 Path Establishment A source uses Address Resolution Protocol in order to establish a path from itself to a destination within the same pure Metro Switch Network. However if a destination does not exist within the same pure Metro Switch Network, a source uses Routing Protocol to discover a corresponding peer. 4.3 Granularity Metro Network should be able to support per-flow signaling in order to use bandwidth efficiently. RSVP-TE uses label switching to realize this. +-----------+ +---------+ |+---------+| | | ||Aggrega- || | | ||tion || | | ||Algorithm|| | | |+---------+| | | | ^ | | | | +--------+ +--------+ | | | | +--------+ | | +------+ |+------+| |+------+| |+------+ | | |+------+| |+------+ | |QoS | ||QoS || ||QoS || ||QoS | | | ||QoS || ||QoS | | |Initi-|-->|Cont- |--->|Cont- |--->|Cont- | | | ||Cont- |-->|Cont- |--> |ator | ||roller|| ||roller|| ||roller| | | ||roller|| ||roller| | Choi, et al. Expires - January 2003 [Page 6] Consideration of RSVP-TE Extension for Metro Network +------+ |+------+| |+------+| |+------+ | | |+------+| |+------+ | | Agent | | Agent | | V | | Agent | | | +--------+ +--------+ | +--------+| +--------+ | | | |QoS || ^ | | | |Initi- || | | | | |ator |------+ | | | +--------+| | | | | |Deaggra- | | Aggregator| |tor | +-----------+ +---------+ | RSVP-TE for | | | Per-Flow Signaling | Per-Aggregation Signaling | |<------------------->|<------------------------------------>| | (Metro Network) | (Backbone Network) | Figure 3: Per-Flow Signaling for Metro Network 4.4 Resilience Backup Label Switched Paths can be configured for fast fail-over, improving overall service reliability. Backup LSPs can be defined as hot-standby LSPs that have been pre-established, or can be dynamically created upon failure of the primary LSP. Another alternative is to enable the fast-reroute option when an LSP is established, leading to the creation of detour LSPs around each point of failure in the path 4.5 Transparency By adding the explicit route object (ERO) to the Path message, the Agent can specify a predetermined explicit route for the Label Switched Path, independent of IP routing. Therefore an explicit route is a specification of groups of agents to be traversed and a set of operations to be performed along the path, i.e. tunnel. 5. Conclusion This draft suggests RSVP-TE as signaling protocol for Metro Network. It is because the size of Metro Network becomes bigger and it could be possible for this area to be congestion point, but there is currently no bandwidth reservation method. Therefore this area necessarily requires bandwidth reservation protocol and fast switching method. To solve the problem, there are some consideration issues adopting RSVP-TE in Metro Network. However RSVP-TE will be able to satisfy bandwidth requirement, for it is based on MPLS that is capable of supporting fast forwarding process and traffic engineering. Choi, et al. Expires - January 2003 [Page 7] Consideration of RSVP-TE Extension for Metro Network References [1] Hancock, R., "Towards a Framework for QoS Signaling in the Internet", draft-hancock-framework-00.txt, February 2002 [2] Brunner, M., "Requirement for QoS Signaling Protocols", draft- brunner-nsis-req-00.txt, November 2001 [3] H. de Meer, "Analysis of Existing QoS Solutions", draft-demeer- nsis-analysis-01.txt, May 2002 [4] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [5] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Estensions to RSVP for LSP Tunnels", RFC 3209, December 2001 Author's Addresses JunKyun Choi Information and Communications University 58-4 Hwa Ahm Dong, Yuseong, Daejeon, Korea 305-732 Phone: +82-42-866-6136 Email: jkchoi@icu.ac.kr Younghun Yoo Information and Communications University 58-4 Hwa Ahm Dong, Yuseong, Daejeon, Korea 305-732 Phone: +82-42-866-6198 Email: yhyoo@icu.ac.kr Choi, et al. Expires - January 2003 [Page 8]