NSIS Working Group J. Zhang
Internet-Draft Queen Mary, Univ. of London
Expires: December 2006 E. Monteiro
University of Coimbra
P. Mendes
DoCoMo Euro-Labs
G. Karagiannis
University of Twente
J. Andres-Colas
Telefonica I+D
InterDomain-QOSM: The NSIS QOS Model for Inter-domain Signaling to
Enable End-to-End QoS Provisioning Over Heterogeneous Network Domains
<draft-zhang-nsis-interdomain-qosm-02.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Zhang, et al. Expires December, 2006 [Page 1]
Internet-Draft InterDomain-QOSM June 2006
Abstract
This document describes a NSIS Inter-domain QoS Model
(InterDomain-QOSM) for realizing automatic inter-domain QoS
interactions between adjacent network domains in a standardized and
dynamic way to facilitate the end-to-end QoS provisioning over
a chain of heterogeneous network domains. Specifically, it adopts the
idea of distinct separation between the intra-domain QoS control
plane and the inter-domain QoS control plane at each administrative
domain and aims at standardizing the interface between the
intra-domain and inter-domain QoS control planes within a domain and
implementing the inter-domain QoS control plane as well as the
inter-domain interface between peer inter-domain control planes by
specifying the InterDomain-QOSM. Furthermore, the interactions
between the intra-domain and inter-domain control planes via the
standardized interface are also described in detail when the NSIS
(e.g., the RMD-QOSM or Y.1541-QOSM) is deployed as the intra-domain
QoS control solution.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Overview of Inter-domain Signaling for End-to-End
QoS Provisioning Over Heterogeneous Network Domains. . . . . 6
3.1 Requirements of Inter-domain QoS Control . . . . . . . . 7
3.2 The Aims and Scope of the InterDomain-QOSM Draft . . . . 9
4. The Assumptions about NSIS . . . . . . . . . . . . . . . . 10
4.1 GIST Analysis . . . . . . . . . . . . . . . . . . . . . 10
4.2 QoS-NSLP Analysis . . . . . . . . . . . . . . . . . . . 13
5. The Basic Features of InterDomain-QOSM . . . . . . . . . . 14
5.1 Role of the Inter-Domain QNE. . . . . . . . . . . . . . 14
5.2 High-level View of InterDomain-QoSM Signaling
and Operations . . . . . . . . . . . . . . . . . . . . 18
6. InterDomain-QOSM, Detailed Description . . . . . . . . . . 21
6.1 Additional QSPEC Parameters for InterDomain-QOSM . . . 21
6.1.1 <Egress ID> parameter . . . . . . . . . . . . . . 22
6.1.2 <Ingress ID> parameter . . . . . . . . . . . . . 23
6.1.3 <Absolute Time Interval Specification> parameter. 23
6.1.4 <Relative Time Interval Specification> parameter. 24
6.2 The Operation Modes of InterDomain-QOSM . . . . . . . . 24
6.2.1 Operation mode 1: fully centralized . . . . . . . 24
6.2.2 Operation mode 2: fully distributed . . . . . . . 25
6.2.3 Operation mode 3: hybrid. . . . . . . . . . . . . 25
6.2.4 Operation mode 4: generalized mode. . . . . . . . 25
6.3 Message Format. . . . . . . . . . . . . . . . . . . . . 26
6.4 InterDomain-QOSM Node State Management. . . . . . . . . 26
6.5 InterDomain-QOSM Operations and Sequences of Events . . 26
6.5.1 Basic unidirectional operation. . . . . . . . . . 26
6.5.1.1 Successful reservation. . . . . . . . . . 26
Zhang, et al. Expires December, 2006 [Page 2]
Internet-Draft InterDomain-QOSM June 2006
6.5.1.2 Unsuccessful reservation. . . . . . . . . 26
6.5.1.3 Refresh reservation . . . . . . . . . . . 26
6.5.1.4 Modification of reservation . . . . . . . 26
6.5.1.5 InterDomain release procedure . . . . . . 26
6.6 Inter-domain QNE Discovery and Transport of
InterDomain-QOSM Messages . . . . . . . . . . . . . . . 26
6.6.1 Requirements of InterDomain-QOSM to
the Underlying Path-coupled NTLP. . . . . . . . . 26
6.6.2 Requirements of InterDomain-QOSM to
the Underlying path-decoupled NTLP. . . . . . . . 26
6.7 Handling of Additional Errors . . . . . . . . . . . . . 27
7. Security Consideration. . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1 Normative References . . . . . . . . . . . . . . . . 28
11.2 Informative References . . . . . . . . . . . . . . . 28
Appendix A. Examples of Discovering Peer Inter-domain QNE
With the Path-decoupled MRM of GIST. . . . . . . . 29
A.1 Under InterDomain-QOSM operation mode 1 . . . 29
A.2 Under InterDomain-QOSM operation mode 2 . . . 29
A.3 Under InterDomain-QOSM operation mode 3 . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property Statement . . . . . . . . . . . . . . . 30
1. Introduction
Although lots of efforts (e.g., IntServ [RFC2210] and Diffserv
[RFC2475], [RFC2638]) have been made by the Internet community to
address efficient Quality-of-Service (QoS) support in IP networks,
there are still some barriers to overcome before the end-to-end QoS
provisioning can be truly realized over heterogeneous IP network
domains. Among them, one major barrier to the achievement of
end-to-end QoS over heterogeneous environments is the lack of a
standardized and automatic approach to perform inter-domain QoS
interactions between adjacent administrative domains. To fully
address this barrier, we believe that a distinct separation between
the intra-domain QoS control plane and the inter-domain QoS control
plane within an administrative domain must be made, an interface
between the intra-domain and inter-domain QoS control planes in the
domain must be clarified and standardized, and an interface between
the peer inter-domain QoS control planes at adjacent domains must be
standardized and implemented in a way that the network operator's
internal confidentials don't need to be exposed. With the above
separation and interfaces, the automatic QoS negotiation and setup of
inter-domain traffic streams over a chain of heterogeneous network
domains will be enabled in a standardized and dynamic way, fully
independent from the intra-domain QoS mechanisms in use at each
domain.
Zhang, et al. Expires December 2006 [Page 3]
Internet-Draft InterDomain-QOSM June 2006
The Next Steps in Signaling (NSIS) Working Group proposed a flexible
IP signaling solution [RFC4080] for the Internet, where the NSIS
protocol suite is structured in two layers: a generic (lower) layer,
termed NSIS Transport Layer Protocol (NTLP), which is responsible for
moving upper-layer signaling messages between NSIS entities and is
independent of any particular signaling applications on top of it;
and an upper layer, termed NSIS Signaling Layer Protocol (NSLP),
which contains functionality such as upper-layer message formats and
sequences, specific to a particular signaling application. Currently,
the General Internet Signaling Transport (GIST) protocol [GIST]
provides a concrete solution for the NTLP. Moreover, the QoS NSIS
Signaling Layer Protocol (QoS-NSLP) [QoS-NSLP] defines message types
and generic QoS control information for supporting the QoS signaling
application together with a class of QoS Models (QOSM). A QOSM
defines the detailed QoS-related procedures and operations (e.g.,
negotiation, setup, update and release of network resources) to
achieve the requested QoS target in a manner that is consistent with
either the QoS control technology in use at a network domain
(intra-domain QOSM) or between adjacent domains (inter-domain QOSM).
The RMD-QOSM [RMD-QOSM] and Y.1541-QOSM [Y.1541-QOSM] are examples of
the NSIS based intra-domain QOSMs.
This document adopts the idea of distinct separation between the
intra-domain QoS control plane and the inter-domain QoS control plane
at each administrative domain and aims at standardizing the interface
between the intra-domain and inter-domain QoS control planes within a
domain and at implementing the inter-domain QoS control plane as well
as the related inter-domain interface between peer inter-domain QoS
control planes at adjacent domains by specifying a NSIS Inter-domain
QoS Model (InterDomain-QOSM). Furthermore, the interactions between
the intra-domain and the inter-domain control planes via the
standardized interface are also described in detail when the NSIS
(e.g., the RMD-QOSM or Y.1541-QOSM) is deployed as the intra-domain
QoS control solution. For the case that non-NSIS solutions are used
as the intra-domain QoS control mechanism, an additional intra-domain
signaling protocol will be needed to implement the standardized
interface between the intra-domain and inter-domain QoS control
planes within an administrative domain, and we leave it to other
drafts to address.
The structure of this specification is as follows. Section 2 defines
terminology, and Section 3 gives an overview of inter-domain
signaling requirements for end-to-end QoS provisioning over
heterogeneous network domains and then describes the aims and scopes
of the InterDomain-QOSM draft. The basic features of the
InterDomain-QOSM are summarized in Section 4 including the high-level
view of inter-domain signaling operations with the InterDomain-QOSM
via the standardized interfaces. The detailed descriptions of the
InterDomain-QOSM, such as the QSPEC [NSIS-QSPEC] parameters, the
operation modes and the signaling procedures and operations for
Zhang, et al. Expires December 2006 [Page 4]
Internet-Draft InterDomain-QOSM June 2006
realizing the inter-domain control plane, etc, are presented in
Section 5. In addition, Section 6 discusses the security
consideration raised by the InterDomain-QOSM and the IANA
considerations are given in Section 7. Finally, Appendix A provides
the examples of discovering the peer inter-domain QNE with the
path-decoupled MRM of GIST when the NSIS is used as the intra-domain
QoS control solution.
2. Terminology
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
[RFC2119].
The terminology defined by GIST [GIST] and QoS-NSLP [QoS-NSLP]
applies to this draft.
In addition, the following terms are used:
Edge node: Node on the boundary of an administrative domain.
Ingress node: Edge node that handles the traffic as it enters the
domain.
Egress node: Edge node that handles the traffic as it leaves the
domain.
Inter-domain QoS controller: Abstract entity which is responsible for
the inter-domain control mechanisms within its administrative domain,
in cooperation with its logically adjacent domains via a common
inter-domain interface. Depending on the kind of domain (size,
network technology, method used to assure the intra-domain QOS,
etc.), the inter-domain QoS controller can be implemented in a
fully centralized, fully distributed or hybrid (i.e. an intermediate
approach between fully centralized and fully distributed) mode.
Please refer to Section 4.1 for the details of the implementation
modes.
Intra-domain QoS controller: An abstract entity which is responsible
for performing all intra-domain control mechanisms in a manner
appropriate to the specific network technology in use at an
administrative domain. As happens with the inter-domain control
agent, it can be implemented in a centralized, decentralized or
hybrid mode.
Customer: Business entity which has the ability to subscribe to the
services offered by providers.
Provider: Business entity which owns an administrative domain and is
Zhang, et al. Expires December 2006 [Page 5]
Internet-Draft InterDomain-QOSM June 2006
responsible for its operation, especially for the provision of
Internet connectivity.
Service Level Agreement (SLA): Contract between a customer, which can
be an end-user or an administrative domain, and an administrative
domain, which acts as a provider, where the provider guarantees that
traffic offered by a customer meeting certain stated conditions, will
receive one or more particular service levels. The guarantees may be
hard or soft, may carry certain tariffs, and may also carry certain
monetary or legal consequences if they are not met.
Service Level Specification (SLS): Technical details of the agreement
specified by a SLA. A SLS has, as its scope, the acceptance and
treatment of traffic meeting certain conditions and arriving from a
certain customer.
3. The Overview of Inter-domain Signaling for End-to-End QoS
Provisioning Over Heterogeneous Network Domains
There are scenarios that can increase their data forwarding
performance by separating the control plane heavy processing from the
data forwarding processing. Such scenarios are for example, described
in [draft-hancock-nsis-pds-problem-03], which achieve this separation
by implementing outsourcing. The outsourcing takes place when nodes
located on the data forwarding give over either the complete or a
part of their control plane responsibilities, such as resource
management, to one or more central controlling entities. Such
scenarios are able to use signaling that can propagate off path
towards the central controlling entities.
Several off path signaling scenarios can be distinguished, but in
this draft we mainly concentrate on the path decoupled type of
signaling, where signaling messages can travel on path but they might
also be transferred to nodes off the data path. Off path signaling
can be realized by using GIST, which can support path decoupled
signaling, see [draft-hancock-nsis-pds-problem-03] and an
inter-domain QOSM that in combination with the QoS-NSLP realizes a
distinct separation between the intra-domain control plane and the
inter-domain control plane at each administrative domain.
Furthermore, the inter-domain QOSM can specify, by using a QSPEC, a
common inter-domain interface between adjacent domains so that the
inter-domain interactions will be fulfilled in a standardized and
dynamic way to facilitate the realization of end-to-end QoS
provisioning over heterogeneous network domains.
Figure 1 shows a high-level view of such distinct separation made at
two adjacent domains. More specific, at each administrative domain,
the intra-domain QoS controller is responsible for performing all
intra-domain control mechanisms in a manner appropriate to the
network technology in use at the domain and the inter-domain QoS
Zhang, et al. Expires December 2006 [Page 6]
Internet-Draft InterDomain-QOSM June 2006
controller implements a common inter-domain control interface and
is responsible for the inter-domain interactions with its peer via
the common inter-domain interface. Note that both the intra-domain
and inter-domain QoS controllers shown in Figure 1 are the abstract
entity, which can be implemented in a centralized or distributed
mode (see Section 5.1). Moreover, the interface between the
intra-domain and inter-domain QoS controller within a domain is
standardized in this document.
+----------------------------+ +----------------------------+
|Domain A | |Domain B |
| | | |
| | | |
| +-------+ +-------+ | | +-------+ +-------+ |
| |Intra- | |Inter- | | | |Inter- | |Intra- | |
| |domain |<<<>>>|domain |<--|---------|-->|domain |<<<>>>|domain | |
| |QoS | |QoS | |Common | |QoS | |QoS | |
| |control| |control| |inter- | |control| |control| |
| +-------+ +-------+ |domain | +-------+ +-------+ |
| (centralized (centralized)|control | (centralized) (centralized |
| or or |interface| or or |
| distributed) distributed | | distributed distributed)|
+----------------------------+ +----------------------------+
<<<>>> = standardized interface between the intra-domain and
inter-domain QoS controller within an administrative domain
<----> = common inter-domain interface between peer inter-domain QoS
controllers at adjacent domains
Figure 1: The high-level view of the inter-domain interactions
between two adjacent domains where the distinct separation
between the intra-domain and inter-domain control planes is
made and a common inter-domain control interface exists.
3.1 The Requirements of the Inter-domain Control Plane
The requirements of the inter-domain control plane (i.e., the
functions provided by the inter-domain control agent in Figure 1)
which is required to implement a common inter-domain control
interface to facilitate the support of end-to-end QoS provisioning
over heterogeneous network domains are summarized below. Note that
they are derived closely based on the ones outlined by the proposed
Diffserv Control Plane Elements (DCPEL) BOF in its document
[DCPEL-requirements] and from some of the requirements provided in
[Y-RACF].
The Requirements of the Inter-domain Control Plane:
o A common inter-domain control interface, which allows the QoS
negotiation and set-up of inter-domain traffic streams while
Zhang, et al. Expires December 2006 [Page 7]
Internet-Draft InterDomain-QOSM June 2006
hiding intra-domain characteristics from inter-domain
interactions (i.e., independent from the specifics of the
intra-domain control plane), must be implemented by the
inter-domain control plane.
o Signaling communications over the common inter-domain interface
must be made based on a well-understood information model for
SLSs. This model should allow the definition of different degrees
of SLSs, from per-flow, more suitable for end-hosts or small
networks, to per-aggregate, more suitable for large networks. It
should also allow the identification of the SLS validity and a set
of time periods over each the SLS must be available (activated),
besides the information about the QoS characteristics.
o The inter-domain control plane at each domain must be able to keep
established and/or available/offered SLSs. The SLS is associated
with the identity of the network domain offering or requesting the
SLS.
o The inter-domain control plane must allow network domains
negotiate and set up SLSs between adjacent domains. Policy
information specific to the requester, or other general policies
must be checked to determine if the requested SLS can the
accepted.
o The inter-domain control plane at each domain must be able to
ensure that the traffic streams its domain sends are in conformity
with the established agreement. Packets might need to be re-marked
from one internal traffic class identifier to the inter-domain SLS
identifier, which then might need to be re-marked from the
inter-domain SLS identifier to another internal traffic class
identifier used at its adjacent domain.
o The inter-domain control plane should be able to:
* support the QoS query, request, response and monitor operations
in a chain of heterogeneous network domains on a per-flow or
per-aggregate basis via the common inter-domain control
interface;
* support the automatic inter-domain adjustment in the scenario
of mobile end customers;
* support bothrelative QoS control and absolute QoS control;
* verify resource availability within its purview;
* support QoS differentiation over various categories of packet
traffic including flows and user designations;
Zhang, et al. Expires December 2006 [Page 8]
Internet-Draft InterDomain-QOSM June 2006
* operate only on authorized requests for QoS;
* make use of the service priority information for priority
handling;
* support the following QoS resource control modes:
a) Push mode: the policy and resource management decisions are
pushed towards the intra-domain control plane
b) Pull mode: the policy and resource management decisions are
requested by the intra-domain control plane upon receiving
path coupled signaling.
o The inter-domain QoS resource control process should consists of
three logical states:
* Authorization: QoS resource is authorized based on operator
specific policy rules
* Reservation: QoS resource is reserved based on authorized
resource and resource availability
* Commitment: QoS resource is committed for the requested
real time flows
3.2 The Aims and Scope of the InterDomain-QOSM Draft
The aims of the InterDomain-QOSM draft are to standardize the
interface between the intra-domain and inter-domain QoS control
planes within an administrative domain and to specify and implement
the inter-domain QoS control plane as well as the related
inter-domain interface between the peer inter-domain control planes
at adjacent domains by specifying a NSIS Inter-domain QoS Model
(InterDomain-QOSM) so that the automatic inter-domain QoS
interactions can be realized in a standardized and dynamic way to
facilitate end-to-end QoS provisioning over heterogeneous network
domains.
The scope of the draft covers the definition of the interface between
the intra-domain and inter-domain QoS control planes within a domain
and the definition and implementation of the inter-domain interface
between peer inter-domain QoS control planes at adjacent domains by
specifying the InterDomain-QOSM. Moreover, the interactions between
the intra-domain and the inter-domain control planes via the
standardized interface are also described in detail when the NSIS
(e.g., the RMD-QOSM or Y.1541-QOSM) is deployed as the intra-domain
QoS control solution. For the case that non-NSIS solutions are used
as the intra-domain QoS control mechanism, an additional intra-domain
signaling protocol will be needed to implement the standardized
interface between the intra-domain and inter-domain QoS control
Zhang, et al. Expires December 2006 [Page 9]
Internet-Draft InterDomain-QOSM June 2006
planes within an administrative domain, and we leave it to other
drafts to address.
4. The Assumptions about NSIS
This section provides the first analysis of how to include the
InterDomain-QoSM in the NSIS protocol stack, by describing a set of
assumptions about NSIS that are central to the development of the
proposed model. This section introduces section 6.6, which allows us
to go back to NSIS with some proposals for adjustments in order to
fulfill all the requirements of the described InterDomain-QoSM.
This section analysis the potential requirements of the
InterDomain-QOSM on the GIST [GIST] and QoS-NSLP [QoS-NSLP]:
i) We analyze the possible impact of the InterDomain-QoSM on GIST,
namely its support for message association between edge devices
and the inter-domain QoS controller, between the inter-domain QoS
controller and the edge devices, and between two inter-domain QoS
controllers (in the case of a distributed operation mode of the
InterDomain-QoSM.
ii) We analyze until what extend can QoS-NSLP signaling and the
defined QSpec be re-used.
As referred in this section, the inter-domain QoS controller
responsible for the InterDomain-QoSM is involved in the NSIS
signaling framework. Hence we'll call it from now on, Inter-domain
QoS NSIS Entity (Inter-Domain QNE).
4.1 GIST Analysis
The NSIS working group is currently developing a protocol suite in
which the signaling messages will be processed on the nodes which
also handle the data flows themselves ("path-coupled signaling").
Complementary to this method, a complementary routing method
partially decoupled from the data path is being analyzed. This new
off-path Message Routing Method (MRM) allows the signaling and data
paths to be partially decoupled, without sacrificing the integration
with routing.
The major assumption that the InterDomain-QoSM makes of NSIS is the
support of an off-path MRM.
The current proposal for an off-path MRM
[draft-hancock-nsis-pds-problem-03] defines two discovery mechanisms,
one starting in one off-path node and finishing in one on-path node,
and another starting in one on-path node and finishing in one
off-path node. Figure 2 illustrates these two methods.
Zhang, et al. Expires December 2006 [Page 10]
Internet-Draft InterDomain-QOSM June 2006
+----------+
| NSLP |
Messaging association +----------+
##########################>>| GIST |
# ....................| C/D-mode |
# . GIST-Response +----------+
+----------+ # . ^ *
| NSLP | # . . *
+----------+ # . . *
| |<<########## . . V
| GIST | . +-.--------+
| C/D-mode |<................... GIST-Query | . GIST |
| |.......................................... D-mode|
+----------+ +----------+ +----------+ +----------+
| | |RAO bypass| |RAO bypass| | |
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
-------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
+----------+
| NSLP |
+----------+ Messaging Association
| GIST |<<##########################
| C/D-mode | #
+----------+ #
* . ^ #
* . . # +----------+
* . . # |Signalling|
V . . # | Appl. |
+-------.-.+ # +----------+
| . .| GIST-Response ##########>>| |
| GIST . .........................................| GIST |
|D-mode . | GIST-Query | C/D-mode |
| ...|......................................>| |
+----------+ +----------+ +----------+ +----------+
| | |RAO bypass| |RAO bypass| | |
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
-------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
---------> = Data flow (and direction)
.........> = GIST D-mode messages (and direction)
<<######>> = GIST C-mode messages (bidirectional)
*********> = Control (off-path node to router)
Figure 2: discovering a downstream off-path node from a on-path node
(top figure) and discovering a downstream on-path node from
an off-path node (bottom figure).
Zhang, et al. Expires December 2006 [Page 11]
Internet-Draft InterDomain-QOSM June 2006
These two methods are of use to discover a inter-domain QNE from an
edge device by which flows enter a domain (ingress device), and for
an inter-domain QNE to discover an edge device by which flows exit a
domain (egress device). However, these two discovery mechanism do not
support the discovery of one QoS controller by its peers. This is a
kind of off-path to off-path discovery mechanism.
The off-path MRM proposal mention "Off-path 'server' discovery from
another off-path node" in section 3.1, but does not describe that
mechanism. Nevertheless, this off-path to off-path discovery
mechanism may be build by using the two methods (on-path to off-path
discovery and vice-versa) described in the off-path MRM proposal by
allowing the configuration of an on-path node for selecting a
specific off-path device. This is one downstream on-path node (i.e.,
the edge routers in the case of the InterDomain-QoSM) should be
configured to select an off-path QoS controller to which its received
GIST-QUERY message should be forwarded.
Figure 3 illustrates the setup of an association between two
off-path inter-domain QNEs located in two different domains. After
the edge QNE1 at Domain A processes the QoS-NSLP message from its
upstream interior QNE, it will connect to the inter-domain QNE1 in
its domain which is configured to serve it (via GIST D-mode or C-mode
depending on the configuration or requirement). Next, the
inter-domain QNE1 sends a GIST-Query message, which is forwarded by
the Edge QNE1 in its domain and intercepted by the Edge QNE3 in
Domain B. Then, this intercepted Query message is forwarded to the
inter-domain QNE2 in Domain B, which is configured to serve Edge
QNE3. To this end, the inter-domain QNE2 at Domain B knows the
necessary info of its peer at Domain A and can send the GIST-Response
message directly to its peer (here, i.e., inter-domain QNE1 at Domain
A). Finally, a message association is set up between them.
Zhang, et al. Expires December 2006 [Page 12]
Internet-Draft InterDomain-QOSM June 2006
Domain A Domain B
Inter-domain QNE1 Inter-domain QNE2
+----------+ +----------+
|Inter-QOSM| Message Association |Inter-QOSM|
+----------+<<############################>>+----------+
| GIST |<...............................| GIST |
| C/D-mode |<.-. GIST-Response | C/D-mode |
+----------+ | +----------+
. . ^
. | .
+-----.----+ . +-----.----+
|Intra.QOSM| | |Intra.QOSM|
+-----.----+ . +-----.----+
| . | | |GIST . |
|GIST . |-.-. |C/D- . |
|C/D- . | |mode . |
|mode .....|....................................... |
+----------+ GIST-Query +----------+
| IP | | IP |
|Forwarding| Data path |Forwarding|
-------------------------------------------------------------->
+----------+ +----------+
Edge QNE1 Edge QNE3
---------> = Data flow (and direction)
.........> = GIST D-mode messages (and direction)
<<######>> = GIST C-mode messages (bidirectional)
Figure 3: discovering a downstream off-path node from an upstream
off-path node.
This off-path discovery mechanism can be applied to discover peer
off-path devices in different networks, as illustrated in Figure 3,
and to discover peer off-path devices inside the same network. The
later may be used in a scenario in which a domain uses distributed
inter-domain QNEs -- a set of inter-domain QNEs each controlling a
subset of edge nodes. The configuration of the inter-domain QNE as
centralized or distributed is introduced in Section 5.1 of this
document.
4.2 QoS-NSLP Analysis
In the example illustrated in Section 4.1, the inter-domain QNEs
implement the InterDomain-QoSM by signaling QoS between domains,
while QoS-NSLP [QoS-NSLP] is used to support an IntraDomain-QoSM.
This is, the inter-domain QNE may trigger a specific ingress device,
which may use QoS-NSLP to signal the needed QoS among all QoS-NSLP
aware routers inside the domain from the triggered ingress device
until the indicated egress device.
Zhang, et al. Expires December 2006 [Page 13]
Internet-Draft InterDomain-QOSM June 2006
However, the use of QoS-NSLP to signal between ingress and egress
devices is not mandatory for the InterDomain-QoSM. Actually, the
InterDomain-QOSM makes no assumptions about the implementation
mechanisms of the IntraDomain-QoSM. That is to say intra-domain
resources may be controlled in a centralized or distributed way,
based on NSIS protocols or not. Nevertheless, a distributed
implementation of the IntraDomain-QoSM based on QoS-NSLP signalling
over several intra-domain QNEs is more close to the work being done
in NSIS (independent from if the intra-domain signalling is done
on-path or off-path based on the use of a new off-path MRM also
inside a domain).
In any case, the InterDomain-QoSM makes use of the messages, objects
and procedures defined by QoS-NSLP for signaling exchanges between
inter-domain QNEs. However, the InterDomain-QoSM depends on the GIST
to discover the peer inter-domain QNEs in adjacent domains. This
means that QoS-NSLP is used to signal between inter-domain QNEs, over
a set of NSIS message associations, as described in section 5.1.
Moreover, the SLS parameters and QoS control information required for
the inter-domain QoS interactions are specified by using/extending
the QSPEC template in [NSIS-QSPEC].
5. The Basic Features of Inter-domainQoSM
The InterDomain-QOSM described in this document assumes the distinct
separation between the intra-domain QoS control plane and
the inter-domain QoS control plane at each administrative domain by
implementing an inter-domain controller through specifying a NSIS
based Inter-domain QoSM (InterDomain-QOSM).
5.1 Role of the Inter-domain QNE
This section provides an introduction to the three possible
implementation methods for the InterDomain QNE and to the type of
message associations they might use. It also gives some insight about
the impact that the IntraDomain-QoSM can have on the setting of the
above mentioned message associations.
There are three possible ways to implement an Inter-domain QNE:
i) Fully centralized, which means that the Inter-domain QNE
functionality is implemented in an interior network node.
ii) Fully distributed, which means that the Inter-domain QNE
functionality is implemented in all edge network nodes.
iii) A hybrid approach of i) and ii), in which the Inter-domain QNE
is co-located with interior network nodes close to edge devices.
This is while in option ii) we have one inter-domain QNE
Zhang, et al. Expires December 2006 [Page 14]
Internet-Draft InterDomain-QOSM June 2006
implemented in each edge router (which does not separate data
and control plane), in this option we have one Inter-domain QNE
controlling a subset of edge devices and we separated the data
from the control plane.
Each of these approaches has advantages and disadvantages. For
instance:
- The centralized option does not need the synchronization between
several Inter-domain QNEs in the same network, but has scalability
and resilience problems. In terms of signaling, it needs an
off-path inter-domain QoS signaling.
- The fully distributed option presents the highest scalability and
resilience properties, but it incorporates the constraint that the
signaling will be processed on the nodes which also handle the
data flows themselves. From the signaling point of view, there is
no need for a new off-path QoS signaling, since the signaling can
be done by using QoS-NSLP in two steps, inter-domain and
intra-domain.
- The hybrid option seems to provide a good compromise between the
de-coupling of signaling and data and the needed scalability and
resilience. In terms of signaling, it needs an off-path
inter-domain QoS signaling. It may also need an off-path NSLP
intra-domain signaling to synchronize the set of Inter-domain
QNEs.
Figure 4 illustrates the usage of message associations for the
operation of inter-domain QNE in a hybrid approach, when considering
a distributed NSIS intra-domain controller at each on-path node. This
is, in this example the end-hosts (attached to Edge QNE1 and QNE4)
signal the network via the QoS-NSLP message. However this
intra-domain QoS-NSLP message is only forwarded until the egress
router (Edge QNE2). Then, this egress router (Edge QNE2) will
transfer the communication to the inter-domain QNE that serves it (in
this example, inter-domain QNE2), over the pre-established message
association. Next, the inter-domain QNE2 interacts with its peer (in
this example, inter-domain QNE3) via inter-domain QoS-NSLP messages
over a pre-established associations between them. In the neigbour
domain, the inter-domain QNE3 transfers the communication signal to
the suitable ingress device (in this case, the Edge QNE3) also over a
pre-established message association. At this point, the edge QNE3
uses the intra-domain QoS-NSLP messages again to signal all on-path
routers until the next egress router (Edge QNE4). In this example,
the edge QNE4 will not pass the communication signal to the
inter-domain QNE4, since the destination host is attached to it.
Zhang, et al. Expires December 2006 [Page 15]
Internet-Draft InterDomain-QOSM June 2006
Domain A Domain B
Inter-domain Inter-domain Inter-domain Inter-domain
QNE1 QNE2 QNE3 QNE4
+-----------+ +-----------+ +-----------+ +-----------+
|InterDomain| |InterDomain|<<#####>>|InterDomain| |InterDomain|
|-QOSM | |-QOSM | |-QOSM | |-QOSM |
+-----------+ +-----------+ +-----------+ +-----------+
| GIST | | GIST | | GIST | | GIST |
| C/D-mode | | C/D-mode | | C/D-mode | | C/D-mode |
+-----------+ +-----------+ +-----------+ +-----------+
<<# #>>
#>> <<#
+-----------+ +-----------+ +-----------+ +-----------+
XX>|IntraDomain| |IntraDomain| |IntraDomain| |IntraDomain|XX>
|-QOSM | |-QOSM | |-QOSM | |-QOSM |
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
|GIST | |GIST | |GIST | |GIST |
|C/D-mode |***|C/D-mode | |C/D-mode |****|C/D-mode |
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
| IP | | IP | | IP | | IP |
|Forwarding | |Forwarding | |Forwarding | |Forwarding |
--------------------------------------------------------------------->
+-----------+ +-----------+ +-----------+ +-----------+
Edge QNE1 Edge QNE2 Edge QNE3 Edge QNE4
---------> = Data flow (and direction)
<<######>> = InterDomain-QOSM signalling via the GIST C-mode messages
***** = IntraDomain-QoSM signalling based on QoS-NSLP
XXX> = end-host interface
Figure 4: message associations for the operation of the inter-domain
QNE in a hybrid approach
If we consider always a distributed NSIS IntraDomain-QoSM as the
intra-domain QoS solution, the interDomain-QoSM follows an approach
similar to the ITU-T RACF pull mode, independently of the way the
inter-domain QNE is implemented. In fact, the message associations
needed to implement the other two approaches of the InterDomain-QoSM
are similar to the one presented in Figure 4, with the following
differences:
a. Fully centralized approach: message associations between
ingress/egress and the central inter-domain QNE and between peer
inter-domain QNEs in adjacent networks.
b. Fully distributed approach: message associations between peer
inter-domain QNEs.
Zhang, et al. Expires December 2006 [Page 16]
Internet-Draft InterDomain-QOSM June 2006
If fact, the most suitable solution (fully centralized, fully
distributed or hybrid) will strongly depend on the characteristics of
the domain, such size, network technology, and method used to assure
QoS. Moreover, it also depends on the used IntraDomain-QoSM. In the
previous examples we always consider the use of a distributed
NSIS-based IntraDomain-QoSM. However, we may also consider the use of
a generalized distributed InterDomain-QoSM, i.e., leave the
definition of the IntraDomain-QoSM open. In this operational mode,
similar to the ITU-T RACF push mode, the message associations for
inter-domain interactions may be as follows: between peer
inter-domain QNEs. Note that a generic interface between the
IntraDomain-QoSM (i.e., the intra-domain QoS control plane) and the
interDomain-QoSM (i.e., the inter-domain QoS control plane) has to be
specified, since the IntraDomain-QoSM is not specified. Figure 5
illustrates the possible message associations and router
configurations.
Domain A Domain B
Inter-domain Inter-domain Inter-domain Inter-domain
QNE1 QNE2 QNE3 QNE4
X X
v v
+-----------+ +-----------+ +-----------+ +-----------+
|InterDomain|<<##>>|InterDomain|<<##>>|InterDomain|<<##>>|InterDomain|
|-QOSM | |-QOSM | |-QOSM | |-QOSM |
+-----------+ +-----------+ +-----------+ +-----------+
|Interface | |Interface | |Interface | |Interface |
|to | |to | |to | |to |
|IntraDomain| |IntraDomain| |IntraDomain| |IntraDomain|
+-----------+ +-----------+ +-----------+ +-----------+
* * * *
* * * *
+----------+ +----------+ +----------+ +----------+
| IP | | IP | | IP | | IP |
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
----------------------------------------------------------------------->
+----------+ +----------+ +----------+ +----------+
Edge Node1 Edge Node2 Edge Node3 Edge Node4
---------> = Data flow (and direction)
<<######>> = InterDomain-QOSM signalling via the GIST C-mode messages
****** = Direct Router configuration
XXX> = end-host interface
Figure 5: Examples of the message associations for the operation of
distributed inter-domain QNEs, with generic
IntraDomain-QoSM
Zhang, et al. Expires December 2006 [Page 17]
Internet-Draft InterDomain-QOSM June 2006
5.2 High-level View of InterDomain-QoSM Signaling and Operations
This section provides an overall view about the interfaces used by
the InterDomain-QoSM to interact with peers in neighbour network
domains, with the IntraDomain-QoSM present in the same network
domain, and with a local manager of Service Level Specifications
(SLS).
The definition of these signalling interfaces is independent from
the way the inter-domain QNE is implemented inside a domain (either
fully centralized, fully distributed, or hybrid), but assume a
distributed IntraDomain-QoSM, as the one that can be implemented
based on QoS-NSLP. Moreover, the InterDomain-QoSM assumes that the
SLSs between adjacent domains have been established by some other
mechanism and those SLSs are maintained at the inter-domain QNE.
Hence it is assumed that there is also one interface between the
InterDomain-QoSM and the SLS manager to allow the former to receive
from the latter information about the available SLSs at each moment
in time.
Since the interaction between the InterDomain-QoSM and the SLS
manager happens before the occurrence of any flow (aggregated or not)
request, the interface between these two components do not show any
time-related numeration on Figure 6. In the Figure 6, the
intra-domain QoS controller represents and implements the
IntraDomain-QoSM in use at a network domain. Although the
InterDomain-QoSM does not need to make any assumption about the way
the IntraDomain-QoSM is implemented, Figure 6 exemplifies an
IntraDomain-QoSM based on QoS-NSLP, in which the latter is used to
configure network resources on on-path router between edge devices of
the same domain.
Zhang, et al. Expires December 2006 [Page 18]
Internet-Draft InterDomain-QOSM June 2006
Source Domain | Transit Domain | Sink Domain
| |
+-------+ | +-------+ | +-------+
| SLS | | | SLS | | | SLS |
|Manager| | |Manager| | |Manager|
+-------+ | +-------+ | +-------+
| | | | |
V | V | V
QoS Trigger +------+ 3| +------+ 6 | +------+
| ^ |Inter |--|->|Inter |-------------|->|Inter |
1| |12 |Domain|10| |Domain| 9 | |Domain|
V | |QoSM |<-|--|QoSM |<------------|--|QoSMin|
+-------+ 2 | | | | | 4 +-------+ | | | 7 +-------+
|Intra |-->|Inter-| | |Inter-|-->|Intra | | |Inter-|-->|Intra |
|Domain-| 11|domain| | |domain| 5 |Domain-| | |domain| 8 |Domain-|
|QoSM1 |<--|QNE | | |QNE |<--|QOSM2 | | |QNE |<--|QoSM3 |
| | |------| | |------| | | | |------| | |
|Intra- | | QoS- | | | QoS- | |Intra- | | | QoS- | |Intra- |
|domain |<->| NSLP | | | NSLP |<->|domain | | | NSLP |<->|domain |
|QNE | |------| | |------| |QNE | | |------| |QNE |
| | | GIST | | | GIST | | | | | GIST | | |
+-------+ +------+ | +------+ +-------+ | +------+ +-------+
GIST: with on-path and off-path MRM
Figure 6: InterDomain-QOSM signalling interfaces
In the InterDomain-QoSM, it is assumed that hosts communicate with
the nearest intra-domain QNE in the attached network to request or
query resources for a set of SLSs (step 1) and will get from the same
intra-domain QNE a response to that action (step 12). It is assumed
that the SLS request made by a host can have a single flow scope or
can have a scope to reach a certain network prefix.
Besides the IntraDomain-QoSM signalling used in steps 1 and 12, all
the other signalling messages illustrated in Figure 6 refer to the
following InterDomain-QoSM interfaces:
a. Inter-Domain QNE / SLS Manager:
- The SLS Manager provides/updates/removes a set of available SLSs
in the InterDomain-QNE. This means, SLSs that were negotiated
between neighbout network domains. Each of these SLSs can have
different scopes, from a specific network prefix until any
reachable prefix (wildcard scope)
b. Inter-Domain QNE / Intra-Domain QNE:
- A intra-domain QNE (e.g. a QoS-NSLP aware edge router) forward
to an inter-domain QNE which serves it (e.g. preconfigured) the
SLS request or query with an indication of the egress node of
the local domain to which the request or query was locally
Zhang, et al. Expires December 2006 [Page 19]
Internet-Draft InterDomain-QOSM June 2006
assigned --- inter-domain QoS interactions are requested
(step 2).
- As a result of a previous request to an inter-domain QNE, an
intra-domain QNE will receive a response with information about
the sucess or not of the inter-domain signalling (step 11)
- After an interDomain signalling, the receptor inter-domain QNE
will have to discover the local ingress node for the received
SLSs, after which it will trigger the intra-domain QNE at that
place (steps 4 and 7)
- As a result of a previous request to an intra-domain QNE, an
inter-domain QNE will receive a response with information about
the sucess or not of the intra-domain signalling (steps 5 and 8)
c. InterDomain-QNE / InterDomain-QNE:
- Based on the information collected in a signalled SLS and on the
knowledge about the ingress node in the adjacent domain, an
inter-domain QNE is able to select its peer inter-domain QNE at
the neighbour domain (inter-domain association) to communicate
with (steps 3 and 6)
- As a result of a previous request to its peer inter-domain QNE,
the initiating inter-domain QNE will receive a response with
information about the sucess or not of the inter-domain
signalling request (steps 9 and 10).
The remainder of this subsection provides an example an end-to-end
operation performed based on the described interfaces.
When a SLS request or query is received by the intra-domain QNE at
the source domain (step 1), the intra-domain QNE authenticates the
request or query and then trigger the intra-domain QoS mechanisms to
reserve the requested resources from the ingress point where the
intra-domain QNE rests until the egrees point provided by the routing
mechanism. In case of a successful reservation, the egress QNE will
forward the SLS request/query to the inter-domain QNE which is
assigned to serve this egress QNE together with the IP address of the
egress node of the source domain (step 2).
The inter-domain QNE at the source domain will then discover the IP
address of the ingress node in the transit network for the request
(e.g. by querying the inter-domain routing protocol at each border
router that it controls about the IP prefix included in the signalled
SLS). After this, the inter-domain QNE will check whether the
received SLS fit in some SLS established between the egress node of
the source domain and the identified ingress node of the transmit
domain. After a successful checkup, the inter-domain QNE constructs a
Zhang, et al. Expires December 2006 [Page 20]
Internet-Draft InterDomain-QOSM June 2006
new QoS-NSLP RESERVE or QUERY message with the QSPEC object
containing all received SLSs, egress and ingress node parameters as
well as the POLICY_DATA object containing its ID and authentication
information, and send the message to its peer at the transit domain
(step 3).
When the inter-domain QNE at the transit domain receives a QoS-NSLP
RESERVE or QUERY message from its peer, it will take the following
actions:
a. Authenticate that the RESERVE or QUERY message is indeed from a
peer by using the information containing in the POLICY_DATA object
of the received message.
b. Check that the SLS parameters containing in the QSPEC object of
the received message fall within the SLS established between the
egress and ingress nodes indicated in the QSPEC object.
c. Determine whether the QoS request or query may be accepted
according to the policies of the domain.
In case of a successful SLS admission control, the inter-domain QNE
at the transit domain sends the SLS parameters to the intra-domain
QNE located at the edge devices which IP address was received in the
SLS (step 4). At this moment, the transit domain performs
intra-domain operations identical to the ones described before and
the result of the intra-domain signaling is sent back in step 5.
After step 5, the transit domain performs similar inter-domain
operations with the sink domain (step 6) as the ones described before
between the source and transit domains.
At the sink domain, the same operations will be performed by the
inter-domain QNE and the intra-domain QNE inside it (steps 7 and 8),
as the ones described before for the transit domain. After step 8,
and as a result of a successfull intra-domain operation, the
inter-domain QNE will exchange QoS-NSLP RESPONSE message (steps 9 and
10), leading to a sucessful reply on steps 11 and 12.
In case of an unsuccessfull QoS request, each inter-domain QNE should
notify the intra-domain QNE that it serves so that the reserved
resources at this domain can be teared down (this step is not
reflected in Figure 6 due to limited space).
6. InterDomain-QOSM, Detailed Description
6.1 Additional QSPEC Parameters for InterDomain-QOSM
First of all, two new QoS control parameters <Egress ID> and
<Ingress ID> need to be added to the QSPEC Control Information of
the InterDomain-QOSM, which describes the IP interfaces of the
Zhang, et al. Expires December 2006 [Page 21]
Internet-Draft InterDomain-QOSM June 2006
egress and ingress nodes to which the signaled traffic stream is
assigned respectively.
Secondly, to describe the time periods over which a SLS will be
available or requested, the following <Time Interval Specification>
parameters are added to the <QoS Desired>, <QoS Available>,
<QoS Reserved> and <Minimum QoS> QSPEC objects of the
InterDomain-QOSM:
<Time Interval Specification> =
<Absolute Time Interval Specification> |
<Relative Time Interval Specification>
where the <Absolute Time Interval Specification> defines a time
period by specifying its starting and ending time points whereas
the <Relative Time Interval Specification> specifies only the length
of a time period. Note that the format of all the additional
parameters follows the one defined in [NSIS-QSPEC].
6.1.1 <Egress ID> parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| Parameter ID | IP-Ver| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Ingress Interface IP Prefix //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Ingress Interface IP Mask //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Ingress Interface IP Prefix //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Ingress Interface IP Mask //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to allow for more than one ingress interface for which the
QSPEC applies, IP prefixes are used to describe the ingress
interfaces instead of IP addresses. In this way, the fields Ingress
Interface IP Prefix specify IP prefixes of the ingress nodes to which
the signaled traffic stream is assigned, while the fields Ingress
Interface IP Mask specify the mask for those prefixes. The four
reserved bits after the Parameter ID field include the IP version
used in the fields Ingress Interface IP Prefix and Ingress Interface
IP Mask. Depending on the IP version used, the length of this field
will vary. All other fields remain the same meanings as defined in
[NSIS-QSPEC].
Zhang, et al. Expires December 2006 [Page 22]
Internet-Draft InterDomain-QOSM June 2006
6.1.2 <Ingress ID> parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| Parameter ID | IP-Ver| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Egress Interface IP Prefix //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Egress Interface IP Mask //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Egress Interface IP Prefix //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Egress Interface IP Mask //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order to allow for more than one egress interface for which the
QSPEC applies, IP prefixes are used to describe the egress interfaces
instead of IP addresses. In this way, the fields Egress Interface IP
Prefix specify IP prefixes of the egress nodes to which the signaled
traffic stream is assigned, while the fields Egress Interface IP Mask
specify the mask for those prefixes. The four reserved bits after the
Parameter ID field include the IP version used in the fields Egress
Interface IP Prefix and Egress Interface IP Mask. Depending on the IP
version used, the length of this field will vary. All other fields
remain the same meanings as defined in [NSIS-QSPEC].
6.1.3 <Absolute Time Interval Specification> parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| Parameter ID |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Point (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Point (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields Starting Point and Ending Point specify the absolute time
values of the starting and ending points of a time period
respectively. The format of the absolute time values follow the one
defined by the IETF Network Time Protocol [NTP]. Both of them must be
nonnegative and are measured in microseconds. Now they are
represented as a 32-bit integer and can be changed afterwards if
necessary. All other fields than the Starting Point and Ending Point
remain the same meanings as defined in [NSIS-QSPEC].
Zhang, et al. Expires December 2006 [Page 23]
Internet-Draft InterDomain-QOSM June 2006
6.1.4 <Relative Time Interval Specification> parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|E|N|T| Parameter ID |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Active Duration (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The field Active Duration specifies the length of a time period
during which a SLS described by other QSPEC parameters will be
available or need to be activated. It must also be nonnegative and
is measured in microseconds. Now it is represented as a 32-bit
integer and can be changed afterwards if necessary. All other fields
than the Active Duration remain the same meanings as defined in
[NSIS-QSPEC].
6.2 The Operation Modes of InterDomain-QOSM
To address the scalability issue for deploying the InterDomain-QOSM
in real IP network domains, three possible ways to implement the
Inter-domain QNE (see Section 5.1) are provided. Moreover, one aim of
this draft is that the inter-domain QoS control plane implemented by
the InterDomain-QOSM should be able to interact with any intra-domain
QoS solution (no matter NSIS based or not) via the standardized
interface between the intra-domain and inter-domain QoS control
planes. With this in mind, four operation modes of the
InterDomain-QOSM have been specified: fully centralized, fully
distributed, hybrid and generalized modes, where the first three
modes are dedicated to the case that the NSIS is deployed as both the
intra-domain QoS control solution (via IntraDomain-QOSM) and
inter-domain QoS control mechanism (i.e., the InterDomain-QOSM) while
the last mode is for the case that the NSIS InterDomain-QOSM is
deployed for the inter-domain control plane and the intra-domain
control mechanism in use is left open. Note that the implementation
details of the first three operation modes are presented in this
document and the last mode is just briefly discussed and its
implementation is left to other drafts to address.
6.2.1 Operation mode 1: fully centralized
In this operation mode, a single off-path NSIS inter-domain QoS
controller that deploys the InterDomain-QOSM will exist at an
administrative domain, which is responsible for all the
inter-domain QoS interaction requests from/to the domain, and the
NSIS intra-domain QoS controller is distributed at each on-path QNE
and deal with the intra-domain QoS control with an IntraDomain-QOSM
in use at the domain. The NSIS message associations necessary for the
inter-domain interactions will exist between the edge QNEs
Zhang, et al. Expires December 2006 [Page 24]
Internet-Draft InterDomain-QOSM June 2006
(ingress/egress) and the inter-domain QoS controller and between peer
inter-domain QoS controllers at adjacent domains.
6.2.2 Operation mode 2: fully distributed
In this operation mode, the InterDomain-QOSM and an IntraDomain-QOSM
in use will co-exist at each edge QNE of an administrative domain and
the InterDomain-QOSM will be responsible only for the inter-domain
QoS interaction requests from/to the edge QNE where it resides. The
NSIS intra-domain QoS controller is also distributed at each on-path
QNE and manage the intra-domain QoS via an IntraDomain-QOSM in use at
the domain. The NSIS message associations necessary for the
inter-domain interactions will exist only between peer edge QNEs at
adjacent domains.
6.2.3 Operation mode 3: hybrid
In this operation mode, a number of off-path NSIS inter-domain QoS
controller will exist at an administrative domain, and each of them
will deploy the InterDomain-QOSM and be responsible for handling the
inter-domain QoS interaction requests from/to a set of edge QNEs.
Normally the set of edge QNEs assigned to different inter-domain QoS
controller should be disjoint to reduce the synchronization
requirement between different inter-domain QoS controllers. The NSIS
intra-domain QoS controller is also distributed at each on-path QNE
and handle the intra-domain QoS via an IntraDomain-QOSM in use at the
domain. The NSIS message associations necessary for the inter-domain
interactions will exist between the edge QNEs (ingress/egress) and
the inter-domain QoS controller and between peer inter-domain QoS
controllers at adjacent domains.
6.2.4 Operation mode 4: generalized mode
In this operation mode, a number of off-path NSIS inter-domain QoS
controller will exist at an administrative domain, and each of them
will deploy the InterDomain-QOSM and be responsible for handling the
inter-domain QoS interactions made through a set of edge nodes in the
domain. Moreover, the intra-domain QoS control plane can deploy any
intra-domain control mechanisms and the interactions between the
intra-domain and inter-domain QoS control planes will be performed
via the standardized interface between them. The NSIS message
associations for the inter-domain interactions will exist only
between peer inter-domain QoS controllers at adjacent domains. Note
that this mode can be applied to effectively support the ITU-T RACF
push mode [Y-RACF]. Due to the fact that an additional intra-domain
signaling protocol is needed to implement the interface between the
intra-domain and inter-domain QoS control planes, we leave the
implementation details of this operation mode to other draft to
address.
Zhang, et al. Expires December 2006 [Page 25]
Internet-Draft InterDomain-QOSM June 2006
6.3 Message Format
TBD
6.4 InterDomain-QOSM Node State Management
TBD
6.5 InterDomain-QOSM Operations and Sequences of Events
TBD
6.5.1 Basic unidirectional operation
TBD
6.5.1.1 Successful reservation
TBD
6.5.1.2 Unsuccessful reservation
TBD
6.5.1.3 Refresh reservation
TBD
6.5.1.4 Modification of reservation
TBD
6.5.1.5 InterDomain release procedure
TBD
6.6 Inter-domain QNE Discovery and Transport of InterDomain-QOSM
Messages
TBD
6.6.1 Requirements of InterDomain-QOSM to the Underlying Path-coupled
NTLP
TBD
6.6.2 Requirements of InterDomain-QOSM to the Underlying path-decoupled
NTLP
TBD
Zhang, et al. Expires December 2006 [Page 26]
Internet-Draft InterDomain-QOSM June 2006
6.7 Handling of Additional Errors
TBD
7. Security Consideration
The operation mode of the InterDomain-QOSM might produce some
security concerns and this will be discussed and clarified later.
8. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434].
InterDomain-QOSM requires a new IANA registry. In addition, this
document also defines 3 new QSPEC parameters for the QSPEC Template,
as detailed in Section 4. Values are to be assigned for them from the
QSPEC Parameter ID registry.
9. Open Issues
This section includes the issues that we will do or we think should
be analysed in the next version of the draft. Currently, the open
issues include:
o All the missing subsections in Section 6 will be done in the next
version of the draft.
o Multiple paths: one border router may have more than one interface
that a signaled SLS may apply to.
o IntraDomain-QoSM: currently, the InterDomain-QOSM in this draft
makes no assumption about the implementation of the
IntraDomain-QOSM, i.e., it can support any intra-domain QoS
control solutions (NSIS based or non-NSIS based) by standardizing
the interface between the intra-domain and inter-domain QoS
control planes in an administrative domain. However, the authors
are not sure that if the NSIS people will like the idea of an
IntraDomain-QoSM that is not based on NSIS (e.g.: direct
configuration of all router by using SNMP or COPS).
o The interface between the inter-domain QoS control plane and the
intra-domain QoS control plane need to be refined based on more
studies and discussions.
o More QSPEC parameters may be needed for the InterDomain-QOSM.
o The support of the automatic inter-domain adjustment in the
scenario of mobile end customers.
Zhang, et al. Expires December 2006 [Page 27]
Internet-Draft InterDomain-QOSM June 2006
10. Acknowledgments
The authors would like to thank John Loughney and Robert Hancock for
the helpful suggestions on this InterDomain-QOSM work.
11. References
11.1 Normative References
[GIST] Schulzrinne, H., and Hancock, R., "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-08 (work in progress),
March 2006.
[QoS-NSLP] Manner, J., Karagiannis, G., McDonald, A. and Bosch, S.,
"NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-08
(work in progress), April 2006.
[RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management
in Diffserv QOS Model," work in progress.
[NSIS-QSPEC] Ash, J., et. al., "QoS-NSLP QSPEC Template," work in
progress.
11.2 Informative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998.
[RFC2638] Nichols K., Jacobson V., Zhang L. "A Two-bit
Differentiated Services Architecture for the Internet", RFC 2638,
July 1999.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June
2005.
[DCPEL-requirements] Mendes, P., and Nichols, K., "Requirements for
DiffServ Control Plane Elements", draft-mendes-dcpel-requirements-00
(work in progress), January 2006.
[draft-hancock-nsis-pds-problem-03] Hancok, R., Kappler, C.,
Quittek, J., Stiemerling, M., "A Problem Statement for
Partly-Decoupled Signalling in NSIS",
Zhang, et al. Expires December 2006 [Page 28]
Internet-Draft InterDomain-QOSM June 2006
draft-hancock-nsis-pds-problem-03, (work in progress), February 2006.
[Y-RACF] "Funtional architecture and requirements for resource and
admission control functions in Next Generation Networks", ITU-T NGN
Draft Recommendation Y-RACF Version 8.1, February 2006.
[Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for
Networks Using Y.1541 QoS Classes," work in progress.
[NTP] Mills, D. L., "Network Time Protocol (Version 3):
Specification, Implementation and Analysis," RFC 1305, March 1992.
Appendix A. Examples of Discovering Peer Inter-domain QNE with the
Path-decoupled MRM of GIST
A.1 Under InterDomain-QOSM operation mode 1
TBD
A.2 Under InterDomain-QOSM operation mode 2
TBD
A.3 Under InterDomain-QOSM operation mode 3
TBD
Authors's Addresses
Jian Zhang
Dept. of Computer Science
Queen Mary, Univ. of London
Mile End, London E1 4NS
UK
Email: jian.zhang@dcs.qmul.ac.uk
Edmundo Monteiro
Dept. of Informatics Engineering
Univ. of Coimbra
Polo II - Pinhal de Marrocos
3030-290 Coimbra, Portugal
Email: edmundo@dei.uc.pt
Paulo Mendes
Future Networking Laboratory
NTT DoCoMo Euro-Labs
Landsbergerstr 312
80687 Munich
Germany
Phone: +49 89 56824 226
Email: mendes@docomolab-euro.com
URI: http://www.docomolab-euro.com/
Zhang, et al. Expires December 2006 [Page 29]
Internet-Draft InterDomain-QOSM June 2006
Georgios Karagiannis
University of Twente
P.O. Box 217
7500 AE Enschede, The Netherlands
Email: g.karagiannis@ewi.utwente.nl
Jorge Andres-Colas
Advanced Networks Planning
Telefonica I+D
Emilio Vargas, 6
28043 Madrid, Spain
Email: jorgeac@tid.es
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Zhang, et al. Expires December 2006 [Page 30]