Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
Internet Engineering Task Force L. Westberg
INTERNET-DRAFT G. Karagiannis
Expires November 2002 D. Partain
V. Rexhepi
Ericsson
May 2002
Framework for Edge-to-Edge NSIS Signaling
draft-westberg-nsis-edge-edge-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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Westberg, et al. Expires November 2002 [Page 1]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
Abstract
Real-time applications impose very strict requirements on the
underlying transmission network that requires a high level of quality
of service (QoS). This level of QoS can only be achieved by means of
QoS management on an end-to-end basis (i.e., end user to end user),
from application to application, potentially across many domains, as
the current Internet is a concatenation of many domains, usually
managed by different QoS administrators (operators).
The requirement for end-to-end QoS management does not necessarily
mean that a single resource reservation protocol must be applied end-
to-end. In fact it is most likely that the end-to-end QoS management
architecture will consist of many interoperable and concatenated QoS
management architectures rather than one global end-to-end QoS
infrastructure. Usually a network consists of three network parts,
i.e., a host to first hop router, access network and the backbone of
the network. Each of these three network parts imposes different
requirements on the provided QoS solution.
This draft describes a framework for NSIS QoS signaling in edge to
edge networks. The main goal is to provide a skeleton for lightweight
edge to edge NSIS signaling in a network. This skeleton would be used
as input to the NSIS "Framework signaling architecture".
Even though designed for edge-to-edge signaling the applicability of
this framework is not to be limited only to signaling between the
edges of a network, but it can be extended in other signaling
scenarios as well, such as end host - to - end host signaling.
The QoS protocol that will be applied in an edge to edge network is
denoted as edge-to-edge NSIS protocol.
Westberg, et al. Expires November 2002 [Page 2]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
Table of Contents
1 Terminology .................................................. 4
2 Introduction and Motivation .................................. 4
3 Framework for Edge-to-Edge NSIS signaling .................... 6
3.1 Framework for Edge-to-Edge NSIS Signaling - Design Objec
tives ..................................................... 7
3.2 Framework for Edge-to-Edge NSIS Signaling - Design Struc
ture ...................................................... 9
3.2.1 NSIS interior-interior (II-Q) Component Features ......... 11
3.2.2 NSIS BN<->BN (BB-Q) Component Features ................... 11
3.2.3 NSIS Host<->BN (HB-Q) Components Features ................ 12
4 Edge-to Edge QoS NSIS Protocol ............................... 12
5 Edge-to-Edge NSIS signaling framework operation .............. 14
6 Conclusion ................................................... 14
7 Appendix A: Examples of Edge-to-Edge NSIS Signaling Mes
sages ..................................................... 14
7.1 NSIS BN<->BN (BB-Q) Signaling Messages ..................... 14
7.2 NSIS Interior <-> Interior (II-Q) Signaling Messages ....... 15
8 Appendix B: Examples of Edge-to-Edge NSIS signaling frame
work operation ............................................ 16
8.1 Normal Operation for Unidirectional Reservation ............ 17
8.2 Fault handling for unidirectional reservation .............. 21
8.3 Normal Operation for bidirectional (successful) reserva
tion ...................................................... 23
9 Authors' Address ............................................. 26
Westberg, et al. Expires November 2002 [Page 3]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
1. Terminology
- End-to-End QoS
QoS management applied in all the domains from end-host
to end-host.
- Edge-to-Edge network
Network wherein the QoS provisioning is co-ordinated by a
single administrator (or operator). This is a single QoS
administrative domain.
- Edge Node
The router boundaries of a single QoS administrative domain.
- Interior Node
Routers inside a single domain, which are not edge nodes.
- Boundary Node
A "box" which represents an endpoint of the local QoS domain
and it is the interworking point between the end-to-end
QoS and local QoS mechanism. This could be a router, BTS,
BSC/RNC, media gateway, etc.
2. Introduction and Motivation
The real time application requirements can only be satisfied by means
of QoS management mechanisms that will have to be applied end-to-end
from one host to the other. When considering the variety of
applications, network access types, the underlying network
technologies (wired and wireless), management policies and
administration of the domains, etc, having a single QoS management
scheme applied end-to-end is not feasible in all networking
scenarios. For example, what might be a good solution for a wired
network is not a good solution for networks with frequent mobility
requirements. Usually a network consists of three network parts,
i.e., a host to first hop router, access network, and the backbone of
the network. Each of these three network parts imposes different
requirements on the provided QoS solution.
Westberg, et al. Expires November 2002 [Page 4]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
Typically an end-to-end QoS management architecture consists of many
interoperable and concatenated QoS management architectures. Each QoS
domain is responsible for taking its own decisions in its own domain-
specific ways. An example is shown in Figure 1, where the end-to-end
QoS management architecture consists of two concatenated QoS domains.
This QoS architecture uses different types of interfaces:
* interior <-> interior interface: provides basic QoS
functionality, such as scalable, simple and fast QoS
provisioning. Due to the fact that different networks
have different characteristics, such as cost of bandwidth
and performance, this basic QoS functionality may differ
from one QoS domain to another.
* BN <-> BN interface: provides the QoS functionality for
a complete QoS domain by interacting with the interior <->
interior interfaces.
* Host <-> BN interface: in addition to the basic QoS
functionality, this interface has to provide a user
with secure access to the network. Therefore, this
interface will have to provide security functions, such
as authentication and authorization.
QoS domain QoS domain
|---------------| |---------------|
| | | |
|---| |---| |---| |---| |---| |---| |---| |---|
| |<->| |<->| |<->| |<->| |<->| |<->| |<->| |
|---| |---| |---| |---| |---| |---| |---| |---|
host | | | | host
|---------------| |---------------|
BN interior BN BN interior BN
(access w/in (edge) (edge) w/in (access
router) domain domain router)
Figure 1: The end-to-end QoS architecture
Different types of QoS requirements are imposed on these interfaces
due to the different characteristics of the interfaces used in the
QoS architecture. In addition, the different parts of the network
often have different service and billing structures, with different
trust models, all of which translate into signaling needs with
varying degrees of complexity. These are the reasons for separating
Westberg, et al. Expires November 2002 [Page 5]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
the end to end QoS management in several edge to edge QoS management
domains.
This draft describes a framework for edge-to-edge NSIS signaling that
can mainly be applied in edge to edge networks, e.g., a QoS domain in
Figure 1.
The basic design goal of this framework is to satisfy the QoS
requirements imposed by characteristics of different interfaces in an
edge-to-edge network, that is:
* interior <-> interior interface
* BN <-> BN interface
Furthermore, due to the fact that the vast majority of the traffic in
typical networks is point-to-point unicast transport the QoS
signaling mechanism must deal with unicast effectively. Therefore,
this framework focuses on point-to-point and unicast scenarios.
The edge-to-edge NSIS framework is also an open framework as it
provides the basis for interoperability with other resource
reservation schemes, AAA mechanisms,etc and can be extended to other
signaling scenarios as well, such as end host - to - end host
signaling.
This draft is organized as follows. Section 3 describes the basic
concepts and design structure of the framework for edge-to-edge NSIS
signaling. Section 4 describes the NSIS edge-to-edge signaling
protocol. Examples of NSIS edge-to-edge signaling protocol messages
and of the functional operation of the edge-to-edge NSIS signaling
framework are given in Appendix A, Appendix B, respectively. Note
that these examples are only used for illustrative purposes.
3. Framework for Edge-to-Edge NSIS signaling
In the QoS architecture as described in Section 2 there are three
types of interfaces defined:
* interior-to-interior
* BN-to-BN
Westberg, et al. Expires November 2002 [Page 6]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
* Host-to-BN
The framework for edge-to-edge NSIS signaling is related only to the
interfaces relevant to a single QoS domain, that is:
* interior <-> interior interface
* BN <-> BN interface
The interior <-> interior interface provides basic QoS functionality,
such as scalable, simple and fast QoS provisioning. Due to the fact
that different networks have different characteristics, such as cost
of bandwidth and performance, this basic QoS functionality may differ
from one QoS domain to another.
The BN <-> BN interface provides the QoS functionality for a complete
QoS domain by interacting with the interior <-> interior interfaces.
The basic idea of the framework is to satisfy the QoS requirements
imposed by the characteristics of interior-to-interior interface and
BN-to-BN interface.
3.1. Framework for Edge-to-Edge NSIS Signaling - Design Objectives
The design of the edge-to-edge NSIS signaling framework is based on
two main design goals.
The first design goal is that the framework should enable scalable,
simple and fast QoS provisioning on interior <-> interior interface
(e.g. interior routers (see Figure 2)). Thus in the nodes on interior
<-> interior interface there will be no per flow states, i.e. the
reservation state will be per QoS traffic class, that will enable
simple and scalable reservation state maintenance and consequently
fast reservations.
The second goal is that the edge-to-edge NSIS signaling framework
should provide QoS guarantees for each flow (microflow or aggregate)
incoming into the edge-to-edge domain. This implies that reservation
requests of each flow on some nodes (e.g. access routers (see Figure
2)) needs to be related to the QoS traffic class reservation state in
the interior nodes.
These two goals are met by separating a complex reservation mechanism
used in some nodes on BN <-> BN interface from a much simpler
Westberg, et al. Expires November 2002 [Page 7]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
reservation mechanism needed in other nodes on interior <-> interior
interface.
In particular, nodes on BN <-> BN interface will maintain per-flow
states i.e., are stateful. In the edge-to-edge NSIS signaling
framework these nodes are denoted as edge nodes (see Figure 2).
However, any nodes that maintain reservation states can satisfy this
requirement. Note that the edge nodes that process the traffic that
is incoming the edge-to-edge domain are denoted as ingress nodes and
the edge nodes that process the traffic that is going out of the
edge-to-edge domain are denoted as egress nodes.
The nodes between these stateful nodes, that is the nodes on interior
<-> interior interface can have a simpler execution by using only one
aggregated reservation state per traffic class. In the NSIS edge-to-
edge framework these nodes are denoted as interior nodes.
The edges will generate reservation requests for each flow (micro-
flow or aggregate), but in order to achieve simplicity in interior
nodes, a measurement-based like approach on the number of the
requested resources per QoS traffic class can be applied. In
practice, this means that the aggregated reservation state per
traffic class in the interior nodes is updated by a measurement-based
algorithm that uses the requested and available resources as input.
Unlike typical measurement based admission control (MBAC) algorithms,
that apply admission control using data traffic measurements and
available resources as input, the edge-to-edge NSIS framework applies
admission control on resource parameter values included in the
reservation requests, i.e. signaling messages and available resources
per traffic c`lass.
edge-to-edge network
|---------------------------|
| |
|-----| |----| |----| |-----|
| |<->| |<->| |<->| |
|-----| |----| |----| |-----|
| |
|---------------------------|
edge interior interior edge
Figure 2: The edge-to-edge NSIS architecture
Besides the two main design objectives the framework for edge-to-edge
NSIS signaling is also intended as an open and extendible framework
Westberg, et al. Expires November 2002 [Page 8]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
as it should provide the basis for interoperability with other
mechanisms for example AAA mechanisms,etc and it can be extended to
other signaling scenarios as well, such as end host - to - end host
signaling.
3.2. Framework for Edge-to-Edge NSIS Signaling - Design Structure
The framework for edge-to-edge NSIS signaling is structured in a
component-based manner (see Figure 3), such that the design
objectives given above are met.
As each interface has a certain set of functions different from the
other interface, in order to distinguish between them, in the
framework design these sets of functionalities are structured into
three types of components (see also Figure 3):
_ _ _ _ _ _ _ _ _ _ _ _
/ \
/ \
Host Edge Interior Interior Edge Host
|----| |---| |----| |----| |----| |----| |---| |----|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|----| |---| |----| |----| |----| |----| |---| |----|
|HB-Q|<--|---|---|HB-Q|---|----|---|----|---|HB-Q|---|---|-->|HB-Q|
|----| |---| |----| |----| |----| |----| |---| |----|
| |<--|---|-->|BB-Q|<--|----|---|----|-->|BB-Q|<--|---|-->| |
|----| |---| |----| |----| |----| |----| |---| |----|
| |<->| |<->|II-Q|<->|II-Q|<->|II-Q|<->|II-Q|<->|---|<->| |
|----| |---| |----| |----| |----| |----| |---| |----|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
|----| |---| |----| |----| |----| |----| |---| |----|
| \ / |
| \ Edge-to-Edge Network / |
| \ _ _ _ _ _ _ _ _ _ _ / |
| end-to-end Protocol |
|<--------------------------------------------------------->|
Figure 3. Hierarchical structure of the edge-to-edge
framework for QoS signaling
* NSIS interior-interior (II-Q) component: must be part of
all the nodes' functionality within a single domain.
Westberg, et al. Expires November 2002 [Page 9]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
This component provides the basic QoS functionality for the
interior nodes. The basic functionality in the interior nodes
is related to the first design goal for the framework (see
Section 3), that is to no per-flow state in interior node.
This component handles the admission control on resource
parameter values included in the reservation requests, i.e.
signaling messages and available resources per QoS traffic
class.
* NSIS BN<->BN (BB-Q) component: must be part of border node
functionality only.
This component provides the QoS functionality for a whole
single QoS domain by interacting with the interior <->
interior interfaces. Thus the second design goal for the
edge-to-edge QoS signaling framework (see Section 3),
i.e. that the framework even though stateless should
associate each reservation to each flow (microflow or
aggregate) in order to provide certain QoS guarantees for
each flow is achieved by these components. Interior nodes
in the edge-to-edge QoS signaling framework will not have
any of this component's functionality.
* NSIS Host<->BN (HB-Q) components: must be part border node
functionality only.
This component provides an interoperation between the
edge-to-edge QoS signaling framework and other external
mechanisms used for QoS management.
In addition to the basic QoS functionality, this interface
has to provide a user with secure access to the network.
Therefore, this component will have to provide interoperation
with security functions, such as authentication and
authorization. Interior nodes in the edge-to-edge QoS
signaling framework will not have any of this component's
functionality.
Each of these components have their own features. These features are
described in the Sections 3.2.1, 3.2.2 and 3.2.3. respectively.
Westberg, et al. Expires November 2002 [Page 10]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
3.2.1. NSIS interior-interior (II-Q) Component Features
NSIS interior-interior (II-Q) component performs the following set of
functions:
* Admission control and/or resource reservation within a node.
* Management of one reservation state per traffic class (e.g.
PHB) by using a combination of the reservation soft state
and explicit release principles.
* Measurement of the user traffic load.
* Stores a pre-configured threshold value on maximal allowable
traffic load (or resources) per traffic class (e.g. PHB).
* Adaptation to load sharing. Load sharing allows interior
nodes to take advantage of multiple routes to the same
destination by sending data via some or all of these
available routes. The signaling protocol has to adapt to
load sharing once it is used.
* Severe congestion notification. This situation occurs as
a result of route changes or a link failure. The NSIS
interior-interior (II-Q) component has to notify the edges
about the occurrence of this network event.
3.2.2. NSIS BN<->BN (BB-Q) Component Features
NSIS BN<->BN (BB-Q) component performs the following set of
functions:
* Admission control and/or resource reservation within
a domain.
* Maintenance of flow identifier and reservation state per flow
(or aggregated flows), e.g. by using soft state refresh.
* Notification of the ingress border node IP address to the
egress border node.
* Notification of lost protocol signaling messages occurred
in the communication path from the ingress border to the
Westberg, et al. Expires November 2002 [Page 11]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
egress border nodes.
* Notification of resource availability in all the nodes
located in the communication path from the ingress to the
egress nodes.
* Severe congestion handling. Due to a route change or a link
failure a severe congestion situation may occur. The egress
border node is notified by NSIS II-Q component when such
a severe congestion situation occurs. By using the BB-Q
component egress border node notifies the ingress border
node about this severe congestion situation. The ingress
node is solving this situation by using a predefined policy,
e.g., refuses new incoming flows and terminates a portion
of the affected flows.
* Transparent transport of NSIS interior-interior (II-Q),
NSIS Host<->BN signaling components.
3.2.3. NSIS Host<->BN (HB-Q) Components Features
NSIS Host<->BN (HB-Q) component functions are dependent on the
protocols used externally to edge-to-edge network. These functions
are related to interoperability with these protocols. One such
function is:
* Mapping of external QoS requests to resource requests used
in the edge-to-edge QoS signaling framework.
4. Edge-to Edge QoS NSIS Protocol
In the edge-to-edge NSIS signaling framework (see Figure 3) there are
two types of protocols used:
* end-to-end QoS protocol used externally to the edge-to-edge
network
* edge-to-edge QoS NSIS protocol used in the edge-to-edge
network
The End-to-end QoS (EEE-QoS) protocol could be any existing
reservation protocol or a new one applied end-to-end (end host to end
host). This protocol is used to signal the QoS requirements of the
Westberg, et al. Expires November 2002 [Page 12]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
end hosts to the border nodes. RSVP is an example of such protocol.
This protocol can also be the protocol developed by NSIS WG.
The Edge-to-Edge QoS NSIS protocol is a new specialized protocol that
is needed for signaling a limited set of QoS requirements related to
interior-to-interior and BN-to-BN interface.
In order to signal the QoS requirements for different components
functionality sets, the edge-to-edge QoS NSIS protocol consists of
the:
* NSIS interior-interior (II-Q) signaling component
This signaling component contains the information needed
for the functionality of the NSIS interior-interior (II-Q)
component for all the nodes in the edge-to-edge network
(see Section 4, Figure 3).
* NSIS BN<->BN (BB-Q) signaling component
This signaling component contains the information needed
for the functionality of the NSIS BN<->BN (BB-Q) component
for all the border nodes in the edge-to-edge network (see
Section 4, Figure 3). This component is not processed in
interior nodes.
* NSIS Host<->BN (HB-Q) signaling component
This component contains the information needed for the
functionality of the NSIS Host<->BN (BB-Q) component for all
the border nodes in the edge-to-edge network (see Section 4,
Figure 3). This component is not processed in interior nodes.
Note that, signaling component related to the NSIS Host<->BN (BB-Q)
component may also be assumed as implicitly part of the edge-to-edge
QoS NSIS protocol functionality. The explicit definition of this NSIS
BN<->BN (BB-Q) signaling component is dependent of the external QoS
mechanisms and security protocols and is left out of this draft.
Definition of edge-to-edge NSIS signaling protocol are outside of the
scope of this draft. However, for illustrative purposes examples of
these messages are given in Appendix A.
Westberg, et al. Expires November 2002 [Page 13]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
5. Edge-to-Edge NSIS signaling framework operation
The edge-to-edge NSIS signaling framework operation is belongs to the
solutions/implementation space and therefore is outside the scope of
this draft.
However, for the sake of clarity of concepts and illustrative
purposes some possible examples of edge-to-edge NSIS signaling
framework operation are given in Appendix B.
6. Conclusion
This draft presents the edge-to-edge NSIS signaling framework, that
can be used as input to the NSIS signaling framework. It is a
simple, scalable framework that enables fast QoS reservations and
provides per flow (microflow or aggregate) QoS guarantees.
Furthermore it is also an interoperable and extendible framework as
it can be extended for signaling scenarios other than edge-to-edge,
such as signaling end-host to end-host.
7. Appendix A: Examples of Edge-to-Edge NSIS Signaling Messages
This Appendix presents examples of messages that can be used for
signaling of the edge-to-edge QoS NSIS protocol signaling components
in the nodes in the communication path in the edge-to-edge network.
Their description in this draft is to be used for illustrating the
functionality of the edge-to-edge QoS signaling framework.
7.1. NSIS BN<->BN (BB-Q) Signaling Messages
Signaling messages that can be used in the communication between the
NSIS BN<->BN (BB-Q) signaling components are:
* Border to Border Reservation Request (BBQ-RQ)
Initiates or updates the BBQ state in the egress. It is
generated by the ingress node.
* Border to Border Reservation Refresh (BBQ-RF)
Refreshes the BBQ states located in the egress. It is
generated by the ingress node.
Westberg, et al. Expires November 2002 [Page 14]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
* Border to Border Release Request (BBQ-LQ)
Explicitly release the BBQ state. It is generated by the
ingress node.
* Border to Border Reservation Report (BBQ-RR)
Reports that a BBQ-RQ/IIQ-RQ message has been received
and that the request has been admitted or rejected. It is
sent by the egress to the ingress node.
* Border to Border Refresh Report (BBQ-FR)
Reports that a BBQ-RF/IIQ-RF message has been received
and has been processed. It is sent by the egress to the
ingress node.
* Border to Border Congestion Report (BBQ-CR)
Used for severe congestion notification and is sent by
egress to ingress.
In all the messages generated by the ingress node in order to
associate the information between the ingress node and egress node in
an edge-to-edge network, an object will be included. i.e. Border to
Border Request Info (BBQ-RI) object. This object is part of any BBQ
message that is sent from the ingress to egress node. It contains the
information that is required by the egress node to associate a IIQ
signaling message to for example the BBQ flow ID and/or the IP
address of the ingress node. It is inserted by the ingress node.
Furthermore in case of bidirectional reservations this object might
have to carry also the amount of resources needed in the reverse
path.
7.2. NSIS Interior <-> Interior (II-Q) Signaling Messages
Signaling messages that can be used in the communication between the
Interior <-> Interior (II-Q) signaling components are:
* Interior to Interior Reservation Request (IIQ-RQ)
Initiates the IIQ reservation state on all nodes located
on the communication path between the ingress and egress
Westberg, et al. Expires November 2002 [Page 15]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
nodes according to the external reservation request. This
message can be encapsulated in the BBQ-RQ (BBQ Reservation
Request) message.
* Interior to Interior Reservation Refresh (IIQ-RF)
Refreshes the IIQ reservation soft state on all nodes
located on the communication path between the ingress and
egress nodes according to the resource reservation request
that was successfully processed by the IIQ functionality
during a previous refresh period. If this reservation state
does not receive a IIQ-RF message within a refresh period,
reserved resources associated to this IIQ-RF message will
be released automatically. This message can be encapsulated
in the BBQ-RF (BBQ Reservation Refresh) message.
* Interior to Interior Release Request (IIQ-LQ)
Explicitly releases the reserved resources for a particular
flow from a IIQ reservation state. Any node that receives
this message will release the requested resources associated
with it, by subtracting the amount of IIQ-LQ requested
resources from the total reserved amount of resources
stored in the IIQ reservation state. This message can be
encapsulated in the BBQ-LQ (BBQ Release Request) message.
8. Appendix B: Examples of Edge-to-Edge NSIS signaling framework
operation
In this Appendix, three illustrative examples of the functional
operation of the edge-to-edge NSIS framework will be described:
* Sender-initiated Unidirectional Normal Operation
Describes the scenario for successful and unsuccessful
unicast reservations between edges of a domain.
* Sender-initiated Fault Handling
Describes the severe congestion handling for unidirectional
reservations between edges of a domain
Westberg, et al. Expires November 2002 [Page 16]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
* Sender initiated Bi-directional Normal Operation
Describes the scenario for successful bi-directional
reservation between edges of a domain.
8.1. Normal Operation for Unidirectional Reservation
This section describes an example of sender-initiated unidirectional
normal operation. This operation is described by means of flow
diagrams of signaling messages used during the sender-initiated
unidirectional normal. In particular, Figure B-1 and Figure B-2
depict the successful reservation and Figure B-3 depicts the
unsuccessful reservation.
In the successful reservation procedure the IIQ-RQ (IIQ- Reservation
Request) and IIQ-RF (IIQ- Reservation Refresh) are encapsulated into
the BBQ-RQ (BBQ- Reservation Request) and BBQ-RF (BBQ- Reservation
Refresh) messages, respectively.
The interior nodes process only the IIQ-RQ and IIQ-RF messages,
respectively. This means that the IIQ information carried by the IIQ
messages is processed and used by the interior nodes, without
processing or using any of the BBQ information.
If a reservation request can be supported by a node then the request
is sent further towards the egress node. If the request can not be
supported by a node, than the IIQ-RQ is marked (special information
in the IIQ-RQ message that can be marked). The BBQ information
contained in the BBQ-RQ and BBQ-RF messages is only processed at the
edge nodes.
Note that each BBQ message generated by the ingress node carries the
Border to Border Request Info (BBQ-RI) object that contains the
information required by the egress node to associate a IIQ signaling
message encapsulated in the BBQ message to for example the BBQ flow
ID and/or the IP address of the ingress node.
The egress nodes receiving the BBQ-RQ or BBQ-RF messages creates a
BBQ Reservation Report (BBQ-RR) or a BBQ Refresh Report (BBQ-FR). If
the IIQ messages that were received by the egress node were marked
than the BBQ report messages will be marked as well. In this way the
egress node will notify the ingress node about the resource
availability in the communication path between the ingress and egress
node.
Westberg, et al. Expires November 2002 [Page 17]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
Ingress Interior Interior Egress
external | | | |
reservation | | |
request | | | |
-------->| BBQ-RQ | | |
|(IIQ- | | |
| Reservation| | |
| Request) | | |
| | BBQ-RQ | |
|----------->|(IIQ-Reservation| |
| | Request) | |
| | | BBQ-RQ |
| |--------------->|(IIQ-Reservation|
| | | Request) |
| | | |external
| | |--------------->|reservation
| | | |request
| | | |--->
| BBQ-Reservation Report |
|<-----------|----------------|----------------|
| | Traffic(user) | |
| | Data | |
-------->|----------->|--------------->|--------------->|--->
external | | | |
reservation | | |
refresh | | | |
-------->| BBQ-RF | | |
|(IIQ- | | |
| Reservation| | |
| Refresh) | | |
| | BBQ-RF | |
|----------->|(IIQ-Reservation| |
| | Refresh) | |
| | | BBQ-RF |
| |--------------->|(IIQ-Reservation|
| | | Refresh) |
| | | |external
| | |--------------->|reservation
| | | |refresh
| | | |--->
| BBQ-Refresh Report| |
|<-----------|----------------|----------------|
| | | |
Figure B-1: Unidirectional Normal operation
for successful reservation
Westberg, et al. Expires November 2002 [Page 18]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
The explicit release procedure is depicted in Figure B-2. The IIQ
Release Request (IIQ-LQ) message is encapsulated within a BBQ-Release
Request (BBQ-LQ) message. Same as previously, interior nodes process
only the IIQ-LQ. The BBQ information contained in the BBQ-LQ is only
processed at the edge nodes.
Ingress Interior Interior Egress
external | | | |
release | | | |
request | | | |
-------->| BBQ-LQ | | |
|(IIQ-Release| | |
| Request) | | |
| | BBQ-LQ | |
|----------->|(IIQ-Release | |
| | Request) | |
| | | BBQ-LQ |
| |------------>|(IIQ-Release |
| | | Request) |
| | | |external
| | |------------>|release
| | | |request
| | | |--->
Figure B-2: Unidirectional Normal operation
for explicit release
The unsuccessful reservation procedure is depicted in Figure B-3. As
already mentioned, if the request can not be supported by a node,
than the IIQ-RQ is marked (special information in the IIQ-RQ message
that can be marked) by this node.
Besides marking this will also include its identity into the IIQ-RQ
message. All the subsequent nodes in the communication path towards
the egress node will just forward the marked IIQ-RQ message without
processing it. The egress node that receives the marked IIQ-RQ it
will create a BBQ Reservation Report message. This message will be
marked as unsuccessful and it will include the identity of the node
that could not support the reservation request.
When the ingress receives the marked BBQ Reservation Report message
it will have to generate a BBQ Release Request/IIQ Release Request
message in order to release unnecessary reserved resources in some
Westberg, et al. Expires November 2002 [Page 19]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
nodes. The IIQ-LQ message will release the same amount of resources
as the amount of resources requested by the IIQ Reservation Request
that could not be supported by a node. All the nodes that process
the IIQ-LQ message will release these requested resources. When the
IIQ-LQ message reaches the node that could not support the
reservation request, the IIQ-LQ message is discarded.
Ingress Interior Interior Egress
external | | | |
reservation | | |
request | | | |
-------->| BBQ-RQ | | |
| (IIQ- | | |
| Reservation| | |
| Request) | | |
| |BBQ-RQ | |
|----------->|(IIQ- | |
| |Reservation | |
| | Request) | |
| | | BBQ-RQ |
| |----------->|(IIQ- |
| | |Reservation |
| | |Request |
| | |(Marked)) |
| | M |external
| | M------------>|reserv-
| | | |ation
| | | |request
| | | |--->
| BBQ-Reservation Report (Marked) |
|<-----------|------------|-------------|
| BBQ-LQ | | |
|(IIQ-Release| | |
| Request) | | |
| | BBQ-LQ | |
|----------->|(IIQ-Release| |
| | Request) | |
| | | |
| |----------->| |
| | | |
| | | |
Figure B-3: Unidirectional Normal operation
for unsuccessful reservation
Westberg, et al. Expires November 2002 [Page 20]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
8.2. Fault handling for unidirectional reservation
This section describes an example of sender-initiated unidirectional
fault handling operation. The fault handling operation explained in
this section is the severe congestion handling procedure. This
operation is described by means of flow diagrams given in Figure B-4.
Severe congestion in a network is a result of a link or router
failure. Routing algorithms in networks will adapt to severe
congestion by changing the routing decisions to reflect changes in
the topology and traffic volume. As a result the re-routed traffic
will follow a new path, which may result in overloaded nodes as they
need to support more traffic than their capacity allows. This is a
severe congestion occurrence in the communication path.
In the edge-to-edge QoS signaling framework this event needs to be
signaled to the ingress nodes. This will be done by the interior
nodes, that will first detect this occurrence and then by means of
signaling messages or data traffic will notify the ingress nodes. The
ingress node has to resolve this situation based on its predefined
policies related to the flows and QoS guarantees.
One can think of various detection and notification methods for the
interior nodes, such as marking of all the data packets passing
through a severe congested node or marking the IIQ signaling messages
only.
In this draft only one method is considered. This is the proportional
marking method, where the number of the remarked data packets is
proportional to the detected overload. The severely congested
interior node will remark the user data packets with with a specific
severe congestion ID, proportionally to the detected overload. Once
the severe congestion marked packets arrive at the egress node, the
egress node will generate a BBQ_Congestion_Report message that will
be sent to the ingress node. This message will contain the over-
allocation volume of the flow in question, e.g., a blocking
probability.
For each flow ID, the egress node will count the number of severe
congested marked bytes and the number of unmarked bytes, and it will
calculate the blocking probability (Pdrop) using the formula (1):
Pdrop = Bm/(Bm + Bu) (1)
where Bm = number of severe congested marked bytes and Bu = number
Westberg, et al. Expires November 2002 [Page 21]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
of unmarked bytes.
The ingress node, based on this blocking probability, might terminate
the flow. That is, for a higher blocking probability there is a
higher chance that the flow will be terminated. If a flow needs to be
terminated, the ingress node will generate a IIQ_Release Request
message for this flow.
Ingress Interior Interior Egress
| | | |
sent) | | | |
user |(sent) | | |
| user data | | |
data | | | |
-------->|---------->| (sent) user data | user data |
| |------------------->S(# marked bytes) |
| | S------------------->|
| | S(# unmarked bytes) |
| | S------------------->|
| | | |
| | | |
| | | |
| (BBQ_Congestion_Report ("S" marked + Pdrop)) |
external |<----------|--------------------|--------------------|
Error | | | |
<--------| | | |
Terminate| | | |
flow? |BBQ-LQ | | |
YES |(IIQ_ | | |
| Release | | |
| Request) | BBQ-LQ | |
| |(IIQ_Release Request) BBQ-LQ |
|---------->| |(IIQ Release Request)
| |------------------->| |
| | |------------------->|
| | | |
| | | |
Figure B-4: Unidirectional edge-to-edge NSIS
operation in case of severe congestion handling
using proportional marking
Westberg, et al. Expires November 2002 [Page 22]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
8.3. Normal Operation for bidirectional (successful) reservation
This section describes an example of sender-initiated bi-directional
normal operation for successful reservation. This operation is
described by means of flow diagrams given in Figure B-5, Figure B-6,
Figure B-7.
The method for bi-directional reservations is based on combining two
uni-directional reservations. This means that the signaling messages
from the sender of the the bi-directional reservation towards a
receiver are likely to follow a different path than messages
traveling in the opposite direction.
The edge nodes that support a bi-directional reservations have to
satisfy the following requirements:
* Be able to distinguish between a uni-directional and a
bi-directional resource reservation BBQ signaling message.
* When an egress node receives a bi-directional BBQ/IIQ
reservation message it will have to construct a
uni-directional BBQ signaling message and an uni-directional
IIQ signaling message that will be sent in the reverse
direction. The destination IP address (and the source IP
address) of this uni-directional IIQ should be such that
it should reach the sender of the bi-directional reservation.
* It should be possible that the ingress and egress create
a BBQ state that maintains a bi-directional flow
specification.
As already mentioned the forwarding path, i.e., ingress to egress,
may be different from the reverse path, i.e., egress to ingress. This
means that the forwarding path and the reverse path may go though
different interior nodes and ingress nodes than the reverse path.
Note that in order to simplify the description of this feature, in
this Section it is considered that the that the ingress/egress pairs
of nodes in the forwarding and reverse path are the same. In practice
these might be different.
The flow diagram examples shown in Figure 5-5, Figure 5-6 and Figure
5-7 are emphasizing the normal operation for an initial bi-
directional reservation, for a refresh procedure and for an explicit
release procedure, respectively.
Westberg, et al. Expires November 2002 [Page 23]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
The ingress node that triggers a bi-directional reservation, (see
Figure 5-5), will send a BBQ-RQ message/IIQ-RQ towards the egress
node. This message will carry the BBQ Request Info object to notify
the egress node that the BBQ-RQ/IIQ-RQ message is a bi-directional
message. Note that this message may also include the amount of
resources that are requested for the reverse path.
These two messages are denoted as IIQ-RQ(forward) and BBQ_ReqInfo(Bi-
forward). The egress by processing the BBQ_ReqInfo object from the
BBQ_ReqInfo(Bi-forward) will recognize the bidirectional resource
request. The egress node will have to reuse the BBQ-RQ, IIQ-RQ (and
the BBQ_ReqInfo object) message for the reverse direction.
These messages are denoted as BBQ-RQ(reverse)/IIQ_RQ(reverse). The
BBQ-RQ(reverse)/IIQ-RQ(reverse) (and BBQ_ReqInfo(reverse)object)
messages are almost the same as the BBQ-RQ(forward)/IIQ-RQ(forward)
messages (almost all fields included in the Bi-forward messages are
copied into the reverse messages). The difference is related to the
IP source and IP destination addresses of these messages that have to
be chosen such that the messages are sent to/from the same
ingress/egress pair of nodes. Moreover, the amount of requested
resources is equal to the amount of resources that has been carried
by the BBQ_ReqInfo(bi-forward) object.
Ingress Interior Interior Egress
| BBQ-RQ (forward)| | |
external|(IIQ-RQ(forward) | | |
request| | BBQ-RQ(forward) | |
------->|---------------->|(IIQ-RQ(forward))| |
| | |BBQ-RQ(forward) |
| |---------------->|(IIQ-RQ(forward))|
| | |---------------->|
| | (BBQ-RQ(reverse) |
| | ((IIQ-RQ(reverse) |
| |<----------------|-----------------|
| BBQ-RQ(reverse)| | |
|(IIQ-RQ(reverse))| | |
|<----------------| | |
| | | |
| BBQ Reservation Report(reverse) | |
|---------------------------------------------------->|
| |BBQ Reservation Report(Bi-forward) |
|<----------------------------------------------------|
Figure B-5: Bi-directional resource reservation flow
diagram for successful reservation (initial reservation)
Westberg, et al. Expires November 2002 [Page 24]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
A similar approach is used for the refresh procedure, see Figure B-6,
and the explicit release procedure, see Figure B-7.
Ingress Interior Interior Egress
| BBQ-RF (forward)| | |
external|(IIQ-RF(forward) | | |
refresh| | BBQ-RF(forward)| |
------->|---------------->|(IIQ-RF(forward) | BBQ-RF(forward)|
| |----------------->| (IIQ-RF(forward))|
| | |----------------->|
| | (BBQ-RF(reverse) |
| | ((IIQ-RF(reverse) |
| |<-----------------|------------------|
| BBQ-RF(reverse)| | |
|(IIQ-RF(reverse))| | |
|<----------------| | |
| | | |
| BBQ Refresh Report(reverse) | |
|---------------- ------------------------------------->|
| |BBQ Refresh Report(Bi-forward) |
|<------------------------------------------------------|
| | | |
Figure B-6: Bi-directional resource reservation flow
diagram for successful reservation (refresh procedure)
Ingress Interior Interior Egress
| BBQ-LQ (forward)| | |
external |(IIQ-LQ(forward) | | |
release | | BBQ-LQ(forward) | |
-------> |---------------->|(IIQ-LQ(forward)) | BBQ-LQ(forward) |
| |----------------->| (IIQ-LQ(forward))|
| | |------------------>|
| | (BBQ-LQ(reverse) |
| | ((IIQ-LQ(reverse) |
| |<-----------------|-------------------|
|BBQ-LQ(reverse) | | |
|(IIQ-LQ(reverse))| | |
|<----------------| | |
| | | |
Figure B-7: Bi-directional resource reservation flow diagram
for successful reservation (explicit release procedure)
Westberg, et al. Expires November 2002 [Page 25]
Internet Draft Framework for Edge-to-Edge NSIS Signaling May 2002
9. Authors' Address
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@era.ericsson.se
Georgios Karagiannis
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645 7500 AP Enschede
The Netherlands
EMail: Georgios.Karagiannis@eln.ericsson.se
David Partain
Ericsson Radio Systems AB
P.O. Box 1248
SE-581 12 Linkoping
Sweden
EMail: David.Partain@ericsson.com
Vlora Rexhepi
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645 7500 AP Enschede
The Netherlands
EMail: Vlora.Rexhepi@eln.ericsson.se
Westberg, et al. Expires November 2002 [Page 26]