NSIS Working Group J. Zhang
Internet Draft E. Monteiro
University of Coimbra
Expiration Date: August 20, 2006 February 19, 2006
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-00.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 August 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a NSIS QoS Model for inter-domain signaling
(InterDomain-QOSM) between adjacent domains to enable end-to-end QoS
provisioning over heterogeneous network domains. Specifically, it
assumes a distinct separation between the intra-domain control plane
and the inter-domain control plane of an administrative domain and
is intended to implement a common inter-domain interface that allows
the QoS negotiation and setup of inter-domain traffic streams while
hiding the heterogeneity of intra-domain control mechanisms in use in
a chain of heterogeneous network domains. The InterDomain-QoSM
in this document first describes its operation mode and then the
additional QSPEC parameters for fulfulling the common inter-domain
interface are specified, followed by the illustrations of how the
InterDomain-QOSM cooperates with some typical intra-domain QOSMs.
Zhang, et al. Expires August 20, 2006 [Page 1]
Internet-Draft InterDomain-QOSM February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4
3. Summary of Inter-domain Signaling Requirements for end-to-end
QoS Provisioning Over Heterogeneous Network Domains . . . . .5
3.1 Inter-domain Control. . . . . . . . . . . . . . . . . . .5
3.2 Inter-domain Signaling Requirements . . . . . . . . . . 6
3.3 Basic Features of InterDomain-QOSM . . . . . . . . . . . 6
3.3.1 Basic features of InterDomain-QOSM . . . . . . . . 6
3.3.2 The operation model of the InterDomain-QOSM . . . .7
4. InterDomain-QOSM, Detailed Description . . . . . . . . . . . 9
4.1 Additional QSPEC Parameters for InterDomain-QOSM . . . . 9
4.1.1 <Ingress Border Router> parameter . . . . . . . . .9
4.1.2 <Absolute Time Specification> parameter . . . . . 10
4.1.3 <Relative Time Specification> parameter . . . . . 10
4.2 Illustrations of Inter-domain Signaling Interactions . .10
4.2.1 Inter-domain signaling for the case that RMD-QOSM
at domain A and Y.1541-QOSM at domain B . . . . . 10
4.2.2 Inter-domain signaling for the case that
Y.1541-QOSM at domain A and RMD-QOSM at domain B..11
4.2.3 Inter-domain signaling for the case that RMD-QOSM
at domain A and non NSIS domain at B . . . . . . .12
4.2.4 Inter-domain signaling for the case that non NSIS
domain at domain A and RMD-QOSM at domain B . . . 12
4.3 The Discovery of Peer Inter-domain Control Agent . . . .13
5. Security Consideration. . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .13
7. Open issues. . . . . . . . . . . . . . . . . . . . . . . . .14
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . .14
9. Normative References . . . . . . . . . . . . . . . . . . . .14
10. Informative References . . . . . . . . . . . . . . . . . . 15
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
12. Intellectual Property Statement . . . . . . . . . . . . . .15
Zhang, et al. Expires August 20, 2006 [Page 2]
Internet-Draft InterDomain-QOSM February 2006
1. Introduction
This document describes a Next Steps In Signaling (NSIS) QoS Model
for inter-domain signaling (InterDomain-QOSM) which aims at
implementing a common inter-domain interface between adjacent domains
so that the inter-domain interactions for provisioning end-to-end QoS
over heterogeneous network domains can be realized automatically and
dynamically while hiding the heterogeneity of the specific network
technology in use at each domain. Nowadays, it is generally believed
in the networking community that, to support end-to-end QoS
provisioning over heterogeneous network domains, a distinct
separation between intra-domain control plane and inter-domain
control plane must be made and a common inter-domain control
interface must be available at each domain that allows the QoS
negotiation and setup of inter-domain traffic streams while hiding
the intra-domain operations from the inter-domain interactions.
The Quality of Service NSIS Signaling Layer Protocol (QoS-NSLP)
[QoS-NSLP] defines message types and generic QoS control information
for supporting a class of QOSMs. A QOSM is a defined mechanism for
achieving QoS-related operations (e.g., negotiation, setup, update
and release of required QoS) in a manner that is consistent with
either the technology in use inside a network domain (intra-domain
QOSM) or the inter-domain interaction defination in use between
adjacent domains (inter-domain QOSM). The IntServ [RFC2210],
RMD-QOSM [RMD-QOSM] and Y.1541-QOSM [Y.1541-QOSM] are examples of
intra-domain QOSMs.
Figure 1 shows a high-level view of inter-domain interactions between
two adjacent domains for supporting end-to-end QoS provisioning over
heterogeneous network domains. Specifically, at each domain, there
exists a single well-known inter-domain control agent, which is
responsible particularly for the inter-domain interactions with its
peer in adjacent domains via a common inter-domain interface. Note
that, the intra-domain control may be implemented by a single
domain-wide agent, or by a group of local agents. The distribution of
intra-domain control over a set of local-agents and the specific
intra-domain control mechanisms will depend on the network technology
in use at each domain. However, the interface between the peer
inter-domain control agent can be standardized to hide the
heterogeneity of the intra-domain control mechanisms and make the
inter-domain control function independent from the intra-domain one.
The InterDomain-QoSM described in this draft is the example of
inter-domain QOSM, which aims at implementing the common inter-domain
interface (see Figure 1) to facilitate the support of end-to-end QoS
provisioning over heterogeneous network domains. Specifically, it
first describes its operation mode for inter-domain interactions and
then the additional QSPEC parameters for fulfulling the common
inter-domain interface are specified, followed by the illustrations
of how the InterDomain-QOSM cooperates with some typical intra-domain
QOSMs.
Zhang, et al. Expires August 20, 2006 [Page 3]
Internet-Draft InterDomain-QOSM February 2006
+----------------------------+ +----------------------------+
|Domain A | |Domain B |
| | | |
| | | |
| +-------+ +-------+ | | +-------+ +-------+ |
| |Intra- | |Inter- | |Common | |Inter- | |Intra- | |
| |domain |<<<>>>|domain |<--|---------|-->|domain |<<<>>>|domain | |
| |control| |control| |Inter- | |control| |control| |
| |agent | |agent | |domain | |agent | |agent | |
| +-------+ +-------+ |Interface| +-------+ +-------+ |
| (centralized (centralized)| | (centralized) (centralized |
| or | | or |
| distributed) | | distributed)|
+----------------------------+ +----------------------------+
<<<>>> = interactions between the intra-domain control agent and
inter-domain control agent inside each domain
<----> = common inter-domain interface between peer inter-domain
control agents at adjacent domains
Figure 1: The high-level view of inter-domain interactions between
two adjacent domains for supporting end-to-end QoS
provisioning over heterogeneous network domains.
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:
Inter-domain control agent: a domain-wide (NSIS-capable) node inside
an administrative domain, which is responsible for the inter-domain
interactions between adjacent domains.
Intra-domain control agent: a domain-wide node (centralized mode) or
a set of local nodes (distributed mode) at an administrative domain,
responsible for all the intra-domain related QoS operations
appropriate to the specific network technology in use at the domain.
Zhang, et al. Expires August 20, 2006 [Page 4]
Internet-Draft InterDomain-QOSM February 2006
Service Level Specification (SLS): is a set of parameters and their
values which together define the service offered to a traffic flow or
a class of service by an administrative domain.
3. Summary of Inter-domain Signaling Requirements for End-to-end QoS
Provisioning Over Heterogeneous Network Domains
3.1. Inter-domain Control
Although a number of QoS architecture (e.g., IntServ [RFC2210] and
Diffserv [RFC2475, RFC2638]) has been proposed by the Internet
Community, there are still some barriers to overcome to realize the
end-to-end QoS provisioning over heterogeneous network domains. One
of them is the lack of an automatic and dynamic approach to control
QoS agreements between network domains. To confront this barrier, it
is generally believed that a distinct separation between intra-domain
control plane and inter-domain control plane must be made and a
common inter-domain control interface must be available at each
domain that allows the standardized QoS negotiation and setup of
inter-domain traffic streams while hiding the heterogeneity of the
intra-domain control mechanisms.
The preliminary requirements for the inter-domain control plane to
support end-to-end QoS provisioning over heterogeneous network
domains are presented below, which are derived closely based on the
ones outlined by the proposed Diffserv Control Plane Elements (DCPEL)
BOF in its document [DCPEL-requirements].
o A common inter-domain control interface must be available,
allowing the QoS set-up of inter-domain traffic streams while
hiding intra-domain characteristics from inter-network operations.
o The inter-domain control interface should be independent from the
specifics of the intra-domain control plane.
o Communication over a 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 Each domain must have a set of policies to coordinate its
activities as provider, customer, or customer-provider of SLSs,
and must keep information about established and available/offered
agreements. This information may be associated with the identity
of the user or network offering or requesting SLSs.
Zhang, et al. Expires August 20, 2006 [Page 5]
Internet-Draft InterDomain-QOSM February 2006
o The inter-domain interface must allow network domains to offer,
request/negotiate and monitor agreements/SLSs. Policy information
specific to the requester, or other general policies must be
checked to determine if the requested agreement can the accepted.
o Each domain must ensure that the data packets it sends are in
conformity with the established agreement or risk of having
packets dropped. Packets should be re-marked from the internal
traffic class identifier to the inter-domain SLS identifier if
needed. At the provider side, packets may be re-marked from the
SLS identifier to its internal traffic class identifier.
o A network domain or end-host should be able to receive information
about the nature of QoS assurances available to a specific
destination network from the attached access network, either upon
attachment or through queries.
o End-to-end signaling may be used to check the available QoS
guarantees in a chain of heterogeneous network domains on a
per-flow or per-aggregate basis.
o Should support mobile end-hosts and networks, which requires
automatic adjustment of inter-domain agreements.
3.2. Inter-domain Signaling Requirements
To fulfill the above requirements for inter-domain control plane, the
initial requirements for the inter-domain signaling between peer
inter-domain control agents (see Figure 1) are summarized below:
o A set of SLS parameters related to the inter-domain interections
while hiding the specific intra-domain control mechanisms must be
well specified. Besides the information about the QoS
characteristics, the parameters describing the time periods over
which the SLS will be available or activated should also be
included.
o The support of signaling operations which perform the QoS query,
request, monitor and response between adjacent domains on a
per-flow or per-aggregate basis.
o The support of signaling operations which perform the end-to-end
QoS query, request, monitor and response across a chain of
heterogeneous domains on a per-flow or per-aggregate basis.
o The support of signaling operations for automatic adjustment of
inter-domain QoS agreements in the case of mobile end-hosts.
3.3. Basic features of InterDomain-QOSM
3.3.1 Basic features of InterDomain-QOSM
The basic features of the InterDomain-QOSM described in this document
include:
Zhang, et al. Expires August 20, 2006 [Page 6]
Internet-Draft InterDomain-QOSM February 2006
o The SLS parameters required for the inter-domain interactions are
specified by using/extending the QSPEC model in [NSIS-QSPEC].
o The signaling operations requested by the inter-domain signaling
requirements in section 3.2 are illustrated by using the QoS-NSLP
messages in [QoS-NSLP].
o The InterDomain-QOSM makes no assumptions about the intra-domain
QoS operations of the intra-domain control agent. The intra-domain
control agent can be centralized or distributed, NSIS-capable or
NSIS-incapable, etc.
o The InterDomain-QOSM makes no assumption about the message routing
method the NTLP might use to discover the peer inter-domain
control agent at the adjacent domain, i.e., it might use a
path-coupled or path-decoupled NTLP.
3.3.2 The operation model of the InterDomain-QOSM
The operation model of the InterDomain-QOSM is illustrated in Figure
2, where the intra-domain control agent of two adjacent
administrative domains deploys the local QOSM1 and QOSM2 respectively
and we make no assumptions about their implementation mechanisms
(e.g., centralized or distributed, NSIS-aware or NSIS-unaware).
Moreover, the inter-domain control agent at each domain is located at
a well-known QNE where the QoS-NSLP is stateful and we make no
assumptions about how the inter-domain control agent will discover
its peer at the adjacent domain. Furthermore, the inter-domain
control agent is dedicated to performing all inter-domain related
interactions, the intra-domain control agent is dedicated to dealing
with all intra-domain related operations and a distinct separation is
made between intra-domain and inter-domain controls.
+-----------------------------+ +---------------------------+
|Domain A Inter- | | Inter- Domain B|
| domain | | domain |
| control | | control |
| agent | | agent |
|To adjacent peer +------+ | | +------+ To adjacent peer|
<-|------------------>|Inter |<-|----|->|Inter |<----------------|->
| |Domain| | | |Domain| |
|intra- +-------+ |QOSM | | | |QOSM | +-------+ |
|domain |local |<->| | | | | |<->|local | |
|trigger|QOSM1 | | | | | | | |QOSM2 | |
| ----->| | |------| | | |------| | | |
| |Intra- | |QoS- | | | |QoS- | |Intra- | |
| |domain | |NSLP | | | |NSLP | |domain | |
| |control| |------| | | |------| |control| |
| |agent | |NTLP* |<-|.-.-|.>|NTLP* | |agent | |
| +-------+ +------+ | | +------+ +-------+ |
| | | |
+-----------------------------+ +---------------------------+
NTLP*: path-decoupled or path-coupled NTLP
Figure 2: Operation model of InterDomain-QOSM
Zhang, et al. Expires August 20, 2006 [Page 7]
Internet-Draft InterDomain-QOSM February 2006
In addition, the basic signaling exchanges for describing the
operation mode of InterDomain-QOSM are shown in Figure 3. First of
all, when a QoS request is created by a trigger inside domain A, the
intra-domain control agent at domain A handles it and then will send
an inter-domain QoS request with the appropriate SLS parameters to
the inter-domain control agent if the initial request needs the
inter-domain interactions with domain B. In that case, the
inter-domain control agent at domain A need construct a RESERVE
message with the InterDomain QSPEC and send it to the peer at domain
B. After receiving the RESERVE message, the inter-domain control
agent at domain B might first check the requested SLSs against the
inter-domain agreements existed between domain A and domain B and
then extract the requested SLS parameters from the RESERVE message
and forward them to the intra-domain control agent at domain B for
processing. In the case that domain B is the destination domain,
the intra-domain control agent at domain B will create and send its
response to the previous QoS request to the inter-domain control
agent at its domain, which will construct and send a RESPONSE message
to the inter-domain peer at domain A. The inter-domain control agent
at domain A then forwards the response to the intra-domain control
agent at its domain, which will finally propagate the response to the
sender of the initial QoS request by using the appropriate mechanisms
in use at the domain.
QNE QNE QNE
Intra-domain Inter-domain Inter-domain Intra-domain
control agent control agent control agent control agent
at Domain A at Domain A at Domain B at Domain B
| |
inter-domain | | inter-domain
interactions | | interactions
<------------------------>| |<--------------------->
| |
QoS request| | | |
---------->| | | |
from intra-| inter-domain | | |
domain +-------------->| | |
trigger | QoS request | RESERVE | |
| +-------------->| |
| | | intra-domain |
| | +------------->|
| | | QoS request |
| | | |
| | | response |
| |<-------------+
| | RESPONSE | |
| |<--------------+ |
| response | | |
|<--------------+ | |
response | | | |
<---------+ | | |
| | | |
Figure 3: Sender-initiated reservation with inter-domain interactions
between two adjacent domains
Zhang, et al. Expires August 20, 2006 [Page 8]
Internet-Draft InterDomain-QOSM February 2006
It can be seen from Figure 3 that all the inter-domain interactions
must be proceeded via the inter-domain control agent and the
intra-domain agent deals with only the intra-domain operations. In
addition, except for the inter-domain control agent, we make no
assumption about the implementation mechanisms of both intra-domain
control agent and QoS triggers. For the case that the intra-domain
control agent is implemented via a NSIS intra-domain QOSM (e.g.,
RMD-QOSM or Y.1541-QOSM), the inter-domain control agent will forward
its processed QoS-NSLP messages to the intra-domain control agent for
the intra-domain processing; thus, the intra-domain control agent
need also to support the InterDomain-QOSM besides its own
intra-domain QOSM. For the case that the intra-domain control agent
is implemented via other mechanisms, the inter-domain control agent
might extract the SLS parameters from the InterDomain QSPEC and
forward these parameters to the intra-domain control agent for
further intra-domain related processing. Several inter-domain
interaction scenarios are illustrated in Section 4.
4. InterDomain-QOSM, Detailed Description
4.1 Additional QSPEC Parameters for InterDomain-QOSM
First of all, one new parameter named <Ingress Border Router> is
added to the QSPEC Control Information of InterDomain-QOSM, which
contains the IP interface of the ingress border router from which the
signaled traffic stream will be admitted into the adjacent next
domain.
Secondly, to describing the time periods over which the SLS will be
available or activated, the following <Time Specification> parameters
are added to the <QoS Desired>, <QoS Available> and <QoS Reserved>
QSPEC objects of InterDomain-QOSM:
<Time Specification> = <Absolute Time Specification> |
<Relative Time Specification>
where the <Absolute Time Specification> specifies the starting and
ending points of a time period over which the SLS will be available
or activated by using the absolute system time values whereas the
<Relative Time Specification> specifies only the length of a time
period over which the SLS will be available or activated and the
starting point of the active period does not matter. Note that the
<Time Specification> is an optional parameter of the <QoS Desired>,
<QoS Available> and <QoS Reserved>.
4.1.1 <Ingress Border Router> 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| 21 | IP-Ver| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang, et al. Expires August 20, 2006 [Page 9]
Internet-Draft InterDomain-QOSM February 2006
The Interface Address specifies the IP interface of the ingress
border router via which the signaled traffic stream will be accepted
into the adjacent domain. It is a read-only parameter.
4.1.2 <Absolute Time 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| 20 |r|r|r|r| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Point (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Point (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Starting Point and Ending Point indicate the starting and ending
points of a time period over which a SLS described by other QSPEC
parameters will be available or need to be activated. 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.
4.1.3 <Relative Time Specification> parameter
The Active Duration indicates the time period over 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.
4.2 Illustrations of Inter-domain Signaling Interactions
Several inter-domain interaction scenarios are illustrated to show
how the InterDomain-QOSM operates at typical inter-domain interaction
scenarios. Note that the purpose of this illustrations is not the
enumeration of all possible scenarios, instead it aims at
demonstrating the operation model in section 3.3.2 by using some
typical intra-domain QOSMs at adjacent domains. Note that throughout
this document, we assume that domain B is the next domain of domain A
along the direction towards the flow destination.
4.2.1 Inter-domain signaling for the case that RMD-QOSM at domain A and
Y.1541-QOSM at domain B
When an egress node at domain A receive a local RESERVE message which
indicates the successful reservation at this domain, it should
construct a InterDomain-QOSM QSPEC based on the QSPEC in the original
RESERVE message. In this case, the InterDomain-QOSM QSPEC contains
all the QSPEC parameters at the original QSPEC as well as one new
parameter that specifies the IP interface of the ingress border
router of domain B from where the signaled traffic flow will be
accepted into domain B. Then, the egress node sends a new RESERVE
message with this InterDomain-QOSM QSPEC to the well-known
inter-domain control agent at its domain, which will store the IP
interface of the egress node and forward the RESERVE message to its
peer at domain B.
Zhang, et al. Expires August 20, 2006 [Page 10]
Internet-Draft InterDomain-QOSM February 2006
When the inter-domain control agent at domain B receives a RESERVE
message, it should first extract the <Ingress Border Router>
parameter and the SLS related parameters from the InterDomain-QOSM
QSPEC and then might perform the authorization of the requested SLS
against the existing inter-domain SLS agreements between domain A
and B. If the authorization result is positive, it will reconstruct a
QSPEC with all the authorized SLS parameters and send a RESERVE
message with the QSPEC to the ingress node at domain B (this ingress
node is discovered via the extracted <Ingress Border Router>
parameter).
Then, the QoS signaling operations at domain B will be proceeded in
the same way as described in [Y.1541-QOSM]. For the case that domain
B is the destination domain, when the RESPONSE message from the QNR
reaches the above ingress node, it will propagate the RESPONSE to the
well-konwn inter-domain control agent at its domain, which continues
forwarding the RESPONSE to its peer at domain A. Then, the
inter-domain control agent at domain A will send this RESPONSE
message to the egress node at its domain from where the signaled
traffic streams flow out of domain A (it can do this because it
stores the IP interface of this egress node before). Next, the
propagation of the RESPONSE message at domain A will follow the same
rules as defined in [RMD-QOSM].
4.2.2 Inter-domain signaling for the case that Y.1541-QOSM at domain A
and RMD-QOSM at domain B
When an egress node at domain A receive a local RESERVE message which
indicates the successful reservation has been made across this
domain, it should construct a InterDomain-QOSM QSPEC based on the
Initiator QSPEC. In this case, the InterDomain-QOSM QSPEC also
contains all the original parameters at the Initiator QSPEC as well
as the <Ingress Border Router> parameter specifying the IP interface
of the ingress border router of domain B for the signaled traffic
flow. Next, this egress node sends a new RESERVE message with the
InterDomain-QOSM QSPEC to the inter-domain control agent at its
domain, which will also store the IP interface of the egress node and
then forward the RESERVE message to its peer at domain B.
As long as the inter-domain control agent at domain B receives one
RESERVE message, it should first extract all the QSPEC parameters
including the <Ingress Border Router> parameter from the
InterDomain-QOSM QSPEC and then might perform the authorization of
the requested SLS against the existing inter-domain SLS agreements
between domain A and B. If the authorization result is positive, it
will reconstruct the Initiator QSPEC with the authorized SLS
parameters and send a RESERVE message with this QSPEC to the ingress
node at domain B (this ingress node is discovered via the extracted
<Ingress Border Router> parameter).
Then, the QoS signaling operations at domain B will be performed in
the same way as described in [RMD-QOSM]. In the case that domain B
is the destination domain, the propagation of the RESPONSE message
is similar as described in section 4.2.1.
Zhang, et al. Expires August 20, 2006 [Page 11]
Internet-Draft InterDomain-QOSM February 2006
4.2.3 Inter-domain signaling for the case that RMD-QOSM at domain A
and non NSIS domain at B
For this case, currently we assume that domain B deploys a
domain-wide intra-domain control agent and inter-domain and
intra-domain control agents will reside together and they interact
with each other via a set of standardized APIs. For the case that the
intra-domain control plane is distributed to a set of local
NSIS-incapable nodes, further discussions and studies are needed.
When an egress node at domain A receive a local RESERVE message which
indicates the successful reservation at this domain, it should
construct a InterDomain-QOSM QSPEC based on the Initiator QSPEC.
Next, the egress node sends a new RESERVE message with this
InterDomain-QOSM QSPEC to the inter-domain control agent of its
domain, which will store the IP interface of the egress node and
then forward the RESERVE message to its peer at domain B.
When the inter-domain control agent at domain B receives the RESERVE
message, it should first extract the <Ingress Border Router>
parameter and the SLS related parameters from the InterDomain-QOSM
QSPEC and then might perform the authorization of the requested SLS
against the existing inter-domain SLS agreements between domain A and
B. If the authorization result is positive, it will send all
authorized QSPEC parameters including the one contained in <Ingress
Border Router> to the intra-domain control agent via the standardized
APIs so that the intra-domain control agent can perform its
reservation operations. For instance, the intra-domain control agent
can first check the requested SLS available or not at domain B via
its admission control algorithms and then make the resource
reservation accordingly.
For the case that domain B is the destination domain, the
intra-domain control agent sends its response to the inter-domain
control agent also via the standardized APIs. Then the inter-domain
control agent will construct a RESPONSE message based on the received
response and send it to the inter-domain control agent at domain A,
which will forward this RESPONSE message to the stored egress node of
domain A. From then on, the propagation of the RESPONSE message at
domain A will follow the same operations as defined in [RMD-QOSM].
4.2.4 Inter-domain signaling for the case that non NSIS domain at
domain A and RMD-QOSM at domain B
For this case, currently we assume that domain A deploys a
domain-wide intra-domain control agent and the inter-domain and
intra-domain control agents reside together and they interact with
each other via a set of standardized APIs. For any other scenarios,
further discussions and studies are needed.
Zhang, et al. Expires August 20, 2006 [Page 12]
Internet-Draft InterDomain-QOSM February 2006
When the intra-domain control agent successfully makes the
reservation for a traffic flow, it will send the inter-domain control
agent the SLS parameters describing the QoS requirements of the flow
and the IP interface of the ingress border router of domain B for the
flow via invoking the RESERVE API exposed by the inter-domain control
agent. Note that we make no assumptions about how the intra-domain
control agent at domain A can discover the IP interface of the
ingress border router through which the signaled flow will be
accepted into domain B and several mechanisms could be used.
When the inter-domain control agent at domain A receives the API
call, it will construct a InterDomain-QOSM QSPEC based on the
received SLS parameters and the IP interface of the ingress border
router of domain B and send a new RESERVE message with the
InterDomain-QOSM QSPEC to its peer at domain B.
As long as the inter-domain control agent at domain B receives the
RESERVE message, it will first extract all contained parameters from
the InterDomain-QOSM QSPEC and then might perform the authorization
of the requested SLS against the existing inter-domain SLS agreements
between domain A and B. When the authorization result is positive,
it will construct a new QSPEC containing all other extracted
parameters except for the <Ingress Border Router> and send it via a
RESERVE message to the ingress node identified by that <Ingress
Border Router>.
Then, the QoS signaling operations at domain B will be proceeded in
the same way as described in [RMD-QOSM]. For the case that domain
B is the destination domain, when the RESPONSE message from the QNR
reaches the above ingress node, it will propagate the RESPONSE to the
well-konwn inter-domain control agent at its domain, which continues
forwarding the RESPONSE to its peer at domain A. Next, the
inter-domain control agent at domain A will process the received
RESPONSE message and then send the relevant response to the
intra-domain control agent via a API between them. From now on, the
intra-domain control agent can inform the flow sender the result of
its reservation request by using its specific intra-domain signaling
mechanisms.
4.3 The Discovery of Peer Inter-domain Control Agent
Mainly, the discovery of peer inter-domain control agent can be
performed either by using the discovery method which will be reported
at a seperate NSIS draft or manual configuration or any other
discovery technique. This document makes no assumptions about that.
5. Security Considerations
The operation mode of the InterDomain-QOSM might produce some
security concerns and this will be discussed and clarified later.
6. 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].
Zhang, et al. Expires August 20, 2006 [Page 13]
Internet-Draft InterDomain-QOSM February 2006
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.
7. Open issues
This section describes the open issues related to the
InterDomain-QOSM. Currently, the following open issues will possibly
need to be discussed and addressed later on.
o The interactions between the intra-domain control agent and the
inter-domain control agent when the intra-domain control agent is
not NSIS-capable. The current solution is that we assume the
inter-domain and intra-domain control agents will reside together
and they interact with each other via a set of standardized APIs.
For the case that the intra-domain control function is distributed
to a set of local agents, the additional solutions will be
studied.
o More QSPEC parameters may be needed for the InterDomain-QOSM.
o The support of signaling operations for automatic adjustment of
inter-domain QoS agreements in the case of mobile end-hosts.
8. Acknowledgments
TBD
9. Normative References
[NSIS-QSPEC] Ash, J., et. al., "QoS-NSLP QSPEC Template," work in
progress.
[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.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
Zhang, et al. Expires August 20, 2006 [Page 14]
Internet-Draft InterDomain-QOSM February 2006
10. Informative References
[DCPEL-requirements] Mendes, P., and Nichols, K., "Requirements for
DiffServ Control Plane Elements", draft-mendes-dcpel-requirements-00
(work in progress), July 2006.
[GIST] Schulzrinne, H., and Hancock, R., "GIST: General Internet
Signaling Transport", draft-ietf-nsis-ntlp-08 (work in progress),
March 2006.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[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.
[RMD-QOSM] Bader, A., et. al., "RMD-QOSM - The Resource Management
in Diffserv QOS Model," work in progress.
[Y.1541-QOSM] Ash, J., et. al., "Y.1541-QOSM -- Y.1541 QoS Model for
Networks Using Y.1541 QoS Classes," work in progress.
11. Authors' Addresses
Jian Zhang
Dept. of Informatics Engineering
Univ. of Coimbra
Polo II - Pinhal de Marrocos
3030-290 Coimbra, Portugal
Email: zhang@dei.uc.pt
Edmundo Monteiro
Dept. of Informatics Engineering
Univ. of Coimbra
Polo II - Pinhal de Marrocos
3030-290 Coimbra, Portugal
Email: edmundo@dei.uc.pt
12. 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.
Zhang, et al. Expires August 20, 2006 [Page 15]
Internet-Draft InterDomain-QOSM February 2006
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 August 20, 2006 [Page 16]