Internet DRAFT - draft-choi-metro-signaling
draft-choi-metro-signaling
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
<draft-choi-metro-signaling-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.
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]
