One document matched: draft-geib-sig-guarandif-00.txt
PADS BOF Ruediger Geib
Internet Draft Deutsche Telekom T-Systems
Document: draft-geib-sig-guarandif-00.txt
Expires: August 2003 February 2003
On demand services with throughput guarantees over DiffServ networks
draft-geib-sig-guarandif-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
On demand Internet services with guaranteed throughput are the major
driver behind QoS signaling architectures. Guaranteeing throughput
between two defined points of a DiffServ network requires a
combination of flow information and Per Hop Behaviour. Handling
aggregates instead of flows as specified by the DiffServ
architecture is the most reasonable attempt to do so. This document
describes an architecture using DiffServ mechanisms to provide
on demand throughput guarantees between two points of a DiffServ
network.
Geib Informative [Page 1]
Throuhput Guarantees over DiffServ February 2003
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.
Table of Contents
1. Introduction...................................................2
1.1 DiffServ based throughput guarantees........................2
1.2 Example.....................................................3
2. Signaling architecture.........................................5
2.1 On path signaling architecture..............................6
2.2 Off path signaling architecture.............................6
3. Security.......................................................6
4. Conclusions....................................................7
Author's Address..................................................7
Full Copyright Statement..........................................7
1. Introduction
On demand Internet services with guaranteed throughput are the major
driver behind QoS signaling architectures. IntServ/RSVP is a first
solution to the issue. Per flow state maintenance kept backbone
providers from deployment. The DiffServ architecture enables
differentiated treatment of packets without per flow state
maintenance. Aggregated RSVP offers a reduction of per flow state
maintenace in backbones. Yet, on demand services with throughput
guarantees aren't generally available. The NSIS WG will specify new
signaling mechanisms which will ease deployment of advanced on
demand services. The NSIS charter limits the resulting standards to
on path signaling and service management. In some cases,
considerable additional signaling and state management requirements
may result from this requirements.
This document describes an architecture providing low service
related signaling requirements while attaining on demand services
with throughput guarantees over a DiffServ network.
1.1 DiffServ based throughput guarantees
Guaranteeing throughput of a communication service requires control
of the resources made available to the transmitted information and
control of admission of sources to the network providing the
throughput guarantee.
Assignment of resources for IP packets requires a non-ambiguous
identification of these packets. The most secure way in doing so is
applied by IntServ/RSVP: the well known 5 tuple of addresses, port
numbers and application. DiffServ reduced the amount of code-space
to be checked per packet to a single byte, resulting in reduced
processor requirements of routers assigning QoS resources to
packets. The DiffServ architecture however supports a one point
Geib Informative [Page 2]
Throuhput Guarantees over DiffServ February 2003
throughput guarantee only: it is valid at the point where the marked
traffic enters another DiffServ domain. A carrier willing to
guarantee a certain throughput for traffic entering his network at a
known origin edge router and leaving his network at a known
destination router would have to assign resources based on DiffServ
Code point in combination with at least the destination IP address.
This would add processing requirements and require changes in
DiffServ router implementations. Adding the two bits reserved for
experimentation, DiffServ allows 256 choices of codepoints. Once a
DiffServ Code Point identifies a differentiated packet treatment as
well as the destination of that packet, a point to point throughput
guarantee is possible without changing current router
implementations of DiffServ. The only thing changed is the
interpretation of the DiffServ Code Point. Clearly, scaleability of
such a solution is severly limited. Still, the benefits make a
close consideration of a service architecture worth being done:
- Destination based on demand resource assignment is required at the
origin edge router only. Hence DSCPs identifying traffic class and
destination on an access link are re-written to a single DSCP
identifying the traffic class within the carrier network.
- Within the carrier network resources are pre-provisioned.
Admission control ensures that new senders are only admitted if
the required network resources still are available. Admission
control is performed for all links passed by guaranteed throughput
traffic from origin to destination edge router.
- providing the throughput service in an on demand mode only reduces
the probability of inactive reservations consuming one of the rare
DSCPs.
- The service operated as described is restricted to a single
carrier network. In principle, the same method may be applied in a
cascaded mode, i.e. at customer to local provider interface and
again at local provider to carrier interface.
- A signaling mechanism must be used to indicate applicable DSCPs to
a sender network and to allow admission control along the links
between origin edge node and destination edge node of the network
providing the throughput guarantee.
1.2 Example
Figure gives an example. Source nodes S1-4 request throughput
guarantees for their traffic to destination nodes D1 and D2 from
the carrier network represented by Source edge routers SER1-2, Core
router C1 and destination edge routers D1-2. The throughput
guarantee expands from Sn-Dn.
Geib Informative [Page 3]
Throuhput Guarantees over DiffServ February 2003
+----+ +----+
| S1 |-----\ /--------| D1 |
+----+ \+----+ / +----+
|SER1| /
+----+ /+----+\ /
| S2 |-----/ \ /
+----+ +----+ +----+/
| C1 |-------|DER1|
+----+ +----+ +----+\
| S3 |-----\ / \
+----+ \+----+/ \
|SER2| \
+----+ /+----+ \ +----+
| S4 |-----/ \--------| D2 |
+----+ +----+
Not assuming any specific signaling architecture, the resulting
resources and admission control decisions may look as follows:
S1-SER1: Available Bandwidth for service 10,
Ressource assignment to D1 4, Session ID D1a, DSCP41
Ressource assignment to D2 2, Session ID D2a, DSCP42
S2-SER1: Available Bandwidth for service 10,
Ressource assignment to D2 3, Session ID D2b, DSCP43
S3-SER2: Available Bandwidth for service 10,
Ressource assignment to D1 2, Session ID D1b, DSCP61
Ressource assignment to D2 3, Session ID D2c, DSCP62
S1-SER1: Available Bandwidth for service 10,
Ressource assignment to D1 2, Session ID D1c, DSCP69
SER1-C1: Available Bandwidth for service 100,
Sum of Reservations 9, Session IDs D1a + D2a + D2b, DSCP4
SER1-C1: Available Bandwidth for service 100,
Sum of Reservations 7, Session IDs D1b + D1c + D2c, DSCP4
C1-DER1: Available Bandwidth for service 100,
Sum of Reservations 16, sum of all sessions, DSCP4
DER1-D1: Available Bandwidth for service 10,
Sum of Reservations 8, Session IDs D1a + D1b + D1c, DSCP4
DER1-D2: Available Bandwidth for service 10,
Sum of Reservations 8, Session IDs D2a + D2b + D2c, DSCP4
"Resource assignment to" is short for resource assignment for
traffic from source x to destination y. Dedicated resources are
assigned at the edge only. The edge routers remark all traffic to
one and the same DSCP. Network internal nodes only monitor the
consumption of their available resources for the service. They
don't assign any resources to any specific edge to edge traffic.
The destination IP address of the individual sessions must be made
available to all nodes involved in admission control. It too must
Geib Informative [Page 4]
Throuhput Guarantees over DiffServ February 2003
be communicated by service related signaling signaling. It was
ommitted for the sake of simplicity in the above example.
The remainder of this document discusses different signaling
architectures applicable to support such a service.
2. Signaling architecture
The signaling architecture supporting this service must enable an
exchange of information between carrier and origin customer network
on one hand and within the carrier network on the other hand. The
destination customer network should be involved in the communication
too.
The following general features must be supported by the signaling
architecture:
- Admission control along all carrrier network links passed by the
traffic desiring a throughput guarantee.
- Checking and assignment of DSCP availablity for the traffic flow.
(If locally no active reservation to the same destination is
existing.)
- Configuration of resources at the origin edge router.
- Maintenance of reservation state.
- Marking a previously locally assigned DSCP as available once a
reservation is released.
- Removal of state in the orgin edge router once the reservation is
released.
- Removal of state from the admission control after release of a
reservation.
Note that only basic requirements are listed here. Accounting,
involvement of the destination customer network and others are
omitted in this version of the draft.
Two carrier network signaling architectures may be used to provide
the service specified above: on path signaling as designed by NSIS
and so called off path signaling. The latter here is interpreted as
centralised service management along the AS path only. The
usefulness of both is briefly analysed in the following.
The signaling messages and procedures themselves probably don't
differ significantly between both signaling architectures.
Compatibility therefore should be a minor issue.
It is assumed that only edge routers assign per DSCP resources.
Packets are remarked to a single and same DSCP once they enter the
first intra-carrier network link. Intermediate nodes and the
destination edge router only perform admission control based on the
session identifier and the destination of this session.
Geib Informative [Page 5]
Throuhput Guarantees over DiffServ February 2003
2.1 On path signaling architecture
In an on path signaling architecture, all carrier network elements
passed by the traffic desiring a throughput guarantee must be
involved in the signaling. The edge router assigns a DSCP and the
resources available for this DSCP. Interior routers of the carrier
network only need to control admission to the pre-provisioned per
link resources. Still, they all must support the signaling protocol
and maintain per link and session reservation state.
Assuming the signaling protocol to be conforming with NSIS, the
service is limited to the IP layer. If the carrier network is based
on MPLS, admission control by intermediate MPLS switches is
impossible.
To ensure fast reaction on route changes, existing reservations must
be frequently refreshed.
2.2 Off path signaling architecture
Ideally, also the customer network supports off path signaling.
Discovery of the network providers centralised service management
system would be greatly simplified. The customer network management
unit signaling for service would directly transmit this information
to the centralised carrier service management system. No router or
MPLS switch in the carrier network must support any new signaling
mechanism.
In a general case, the customer isn't aware of the signaling
architecture of the carrier. The edge routers of the carrier network
must at least identify the signaling packets, store their origing
address and session ID and forward them to the centralised service
management system. Further state maintenace is not required.
Interior routers or MPLS switches still aren't involved into
signaling.
As mentioned above, MPLS switches aren't involved into signaling.
Off path signaling enables interworking with MPLS domains.
To perform per link admission control within the carrier domain, the
carriers centralised service management system must be aware of the
actual network topology and routing table. Therefore, it must be
listening passively to route-announcements. It will adjust admission
control decisions as soon as route changes occur. The refresh
mechanism isn't required to track route changes. Refreshes therefore
are required less frequently. The signaling processing is reduced
significantly.
3. Security
In general, security aspects and threats of NSIS and DiffServ apply.
It may be worth noting that off path signaling requires discovery of
peer signaling units prior to signaling for service while this isn't
necessarily the case for on path signaling. Especially the first
Geib Informative [Page 6]
Throuhput Guarantees over DiffServ February 2003
message of a new client may provide no means of authentication in
the on path case. Hence it may be more difficult to protect an on
path signaling system from DoS attacks than an off path signaling
system.
Further, validation and administration of DSCPs at edge routers will
require further attention. Compromising security must be prevented
also if a carrier signaling system breaks or if the access link
fails. A later issue of this draft will address the subject in more
detail
4. Conclusions
A lightweight architecture supporting point to point throughput
guarantees across DiffServ networks was described. No changes in
router DiffServ implementation are required. Scalability issues
demand the service to be available on demand only. Further, the
service is restricted to single DiffServ networks (ASes).
A brief analysis comparing on path signaling for this service with
off path signaling was made. In the off path case, no or only
minimum signaling support is required by routers. Off path
signaling enables interworking of IP and MPLS networks. While the
off path approach currently isn't followed by the NSIS WG, the
signaling protocol developed there should be applicable also in the
off path signaling architecture described here.
Author's Address
Ruediger Geib
T-Systems Nova
Am Kavalleriesand 3
64295 Darmstadt
Germany
Email: Ruediger.Geib@t-systems.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 languages other than
English.
Geib Informative [Page 7]
Throuhput Guarantees over DiffServ February 2003
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires: August 2003
| PAFTECH AB 2003-2026 | 2026-04-23 22:47:13 |