draft-ietf-nsis-req-04.txt   draft-ietf-nsis-req-05.txt 
Network Working Group M. Brunner (Editor) Network Working Group M. Brunner (Editor)
Internet Draft NEC Internet Draft NEC
Category: Informational August 2002 Category: Informational November 2002
Requirements for Signaling Protocols Requirements for Signaling Protocols
<draft-ietf-nsis-req-04.txt> <draft-ietf-nsis-req-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document defines requirements for signaling across different This document defines requirements for signaling across different
network environments, where different network environments across network environments, where different network environments mean
administrative and technology domains. Signaling is mainly though across administrative and technology domains. Signaling is mainly
for QoS such as [1], however in recent year several other though for QoS such as [RSVP], however in recent year several other
applications of signaling have been defined such as signaling for applications of signaling have been defined such as signaling for
MPLS label distribution [2]. To achieve wide applicability of the MPLS label distribution [RSVP-TE]. To achieve wide applicability of
requirements, the starting point is a diverse set of scenarios/use the requirements, the starting point is a diverse set of
cases concerning various types of networks and application scenarios/use cases concerning various types of networks and
interactions. We also provide an outline structure for the problem, application interactions. This memo present the assumptions and the
including related terminology. Taken with the scenarios, this allows aspects not considered within scope before listing the requirements
us to focus more precisely on which parts of the overall problem grouped according to areas such as architecture and design goals,
need to be solved. We present the assumptions and the aspects not signaling flows, layering, performance, flexibility, security, and
considered within scope before listing the requirements grouped mobility.
according to areas such as architecture and design goals, signaling
flows, layering, performance, flexibility, security, and mobility.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
Abstract...........................................................1 Abstract...........................................................1
Table of Contents..................................................2 Table of Contents..................................................1
1 Introduction...................................................3 1 Introduction.....................................................2
2 Terminology....................................................4 2 Terminology......................................................3
3 Problem Statement and Scope....................................6 3 Problem Statement and Scope......................................5
4 Assumptions and Exclusions.....................................8 4 Assumptions and Exclusions.......................................6
4.1 Assumptions and Non-Assumptions..............................8 4.1 Assumptions and Non-Assumptions................................6
4.2 Exclusions...................................................9 4.2 Exclusions.....................................................7
5 Requirements..................................................11 5 Requirements.....................................................9
5.1 Architecture and Design Goals...............................11 5.1 Architecture and Design Goals..................................9
5.1.1 MUST be applicable for different technologies...............11 5.2 Signaling Flows...............................................11
5.1.2 Resource availability information on request................12 5.3 Messaging.....................................................12
5.1.3 NSIS MUST be designed modular...............................12 5.4 Control Information...........................................14
5.1.4 NSIS MUST decouple protocol and information.................12 5.5 Performance...................................................15
5.1.5 NSIS MUST reuse existing QoS provisioning...................12 5.6 Flexibility...................................................17
5.1.6 Independence of signaling and provisioning paradigm.........12 5.7 Security......................................................18
5.1.7 Application independence....................................13 5.8 Mobility......................................................20
5.2 Signaling Flows.............................................13 5.9 Interworking with other protocols and techniques..............21
5.2.1 Free placement of NSIS Initiator, Forwarder, Responder......13 5.10 Operational..................................................21
5.2.2 No constraint of the signaling and NSIS Forwarders to be in 6 Security Considerations.........................................22
the data path.....................................................13 7 References......................................................22
5.2.3 Concealment of topology and technology information..........14 8 Acknowledgments.................................................22
5.2.4 Transparency of signaling to network........................14 9 Author's Addresses..............................................23
5.3 Additional information beyond signaling for a service.......14 10 Appendix: Scenarios/Use cases..................................23
5.3.1 Explicit release of resources...............................14 10.1 Terminal Mobility............................................24
5.3.2 Possibility for automatic release of resources after failure15 10.2 Cellular Networks............................................26
5.3.3 Notifications sent upstream.................................15 10.3 UMTS access..................................................27
5.3.4 Feedback about success of service request...................16 10.4 Wired part of wireless network...............................28
5.3.5 Local information exchange..................................16 10.5 Session Mobility.............................................29
5.4 Control Information.........................................16 10.6 QoS reservations/negotiation from access to core network.....30
5.4.1 Mutability information on parameters........................16 10.7 QoS reservation/negotiation over administrative boundaries...30
5.4.2 Possibility to add and remove local domain information......17 10.8 QoS signaling between PSTN gateways and backbone routers.....31
5.4.3 Independence of reservation identifier......................17 10.9 PSTN trunking gateway........................................32
5.4.4 Seamless modification of already reserved resources.........17 10.10 Application request end-to-end QoS path from the network....34
5.4.5 Grouping of signaling for several microflows................17
5.5 Performance.................................................17
5.5.1 Scalability.................................................18
5.5.2 Low latency in setup........................................18
5.5.3 Allow for low bandwidth consumption for signaling protocol..18
5.5.4 Ability to constrain load on devices........................18
5.5.5 Highest possible network utilization........................19
5.6 Flexibility.................................................19
5.6.1 Flow aggregation............................................19
5.6.2 Flexibility in the placement of the NSIS Initiator..........19
5.6.3 Flexibility in the initiation of re-negotiation.............19
5.6.4 Uni / bi-directional reservation............................19
5.7 Security....................................................20
5.7.1 Authentication of signaling requests........................20
5.7.2 Resource Authorization......................................20
5.7.3 Integrity protection........................................20
5.7.4 Replay protection...........................................20
5.7.5 Hop-by-hop security.........................................20
5.7.6 Identity confidentiality and location privacy...............21
5.7.7 Denial-of-service attacks...................................21
5.7.8 Confidentiality of signaling messages.......................21
5.7.9 Ownership of a reservation..................................21
5.7.10 Hooks with Authentication and Key Agreement protocols......22
5.8 Mobility....................................................22
5.8.1 Allow efficient QoS re-establishment after handover.........22
5.9 Interworking with other protocols and techniques............23
5.9.1 MUST interwork with IP tunneling............................23
5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6......23
5.9.3 MUST be independent from charging model.....................23
5.9.4 SHOULD provide hooks for AAA protocols......................23
5.9.5 SHOULD interwork with seamless handoff protocols............23
5.9.6 MAY interwork with non-traditional routing..................23
5.10 Operational................................................23
5.10.1 Ability to assign transport quality to signaling messages..23
5.10.2 Graceful fail over.........................................24
5.10.3 Graceful handling of NSIS entity problems..................24
6 Security Considerations.......................................24
7 Reference.....................................................24
8 Acknowledgments...............................................24
9 Author's Addresses............................................25
10 Appendix: Scenarios/Use cases.................................25
10.1 Terminal Mobility..........................................25
10.2 Cellular Networks..........................................27
10.3 UMTS access................................................28
10.4 Wired part of wireless network.............................30
10.5 Session Mobility...........................................31
10.6 QoS reservations/negotiation from access to core network...32
10.7 QoS reservation/negotiation over administrative boundaries.32
10.8 QoS signaling between PSTN gateways and backbone routers...33
10.9 PSTN trunking gateway......................................34
10.10 Application request end-to-end QoS path from the network...36
1 Introduction 1 Introduction
This document defines requirements for signaling across different This document defines requirements for signaling across different
network environments. It does not list any problems of existing network environments. It does not list any problems of existing
signaling protocols such as RSVP [1]. signaling protocols such as [RSVP].
In order to derive requirements for signaling it is necessary to In order to derive requirements for signaling it is necessary to
first have a clear idea of the scope within which they are first have an idea of the scope within which they are applicable.
applicable. Therefore, we describe a set of signaling scenarios and use cases in
the Appendix of that document. These scenarios derive from a variety
We describe a set of QoS signaling scenarios and use cases in the of backgrounds, and help obtain a clearer picture of what is in or
Appendix of that document. These scenarios derive from a variety of out of scope of the NSIS work. They illustrate the problem of
backgrounds, and help obtain a clearer picture of what is in or out
of scope of the NSIS work. They illustrate the problem of QoS
signaling from various perspectives (end-system, access network, signaling from various perspectives (end-system, access network,
core network) and for various areas (fixed line, mobile, wireless core network) and for various areas (fixed line, mobile, wireless
environments). environments). Most of them are targeted towards QoS, because that
was the primary target of signaling.
Based on these scenarios, we are able to define the signaling
problem on a more abstract level. In Section 3, we thus present a
simple conceptual model of the signaling problem. Additionally, we
describe the entities involved in signaling and typical signaling
paths. In Section 4 we list assumptions and exclusions.
The model of Section 3 allows deriving requirements from the
scenarios presented in the appendix in a coherent and consistent
manner. Requirements are grouped according to areas such as
Architecture and design goals, Signaling Flows, Layering,
Performance, Flexibility, Security and Mobility.
QoS is a pretty large field with a lot of interaction with other
protocols, mechanisms, applications etc. However, it is not the
only field where signaling is used in the Internet. Even if this
requirement documents mainly used QoS as the sample application
other application should be possible.
It is clear that the subject of QoS is uniquely complex and any QoS and signaling for QoS is a pretty large field with a lot of
investigation could potentially have a very broad scope - so broad interaction with other protocols, mechanisms, applications etc.
that it is a challenge to focus work on an area, which could lead to However, it is not the only field where signaling is used in the
a concrete and useful result. This is our motivation for considering Internet. Even if this requirement documents mainly used QoS as the
a set of use cases, which map out the domain of application that we sample application other application must be possible.
want to address. It is also the motivation for defining a problem
structure, which allows us to state the boundaries of what types of
functionality to consider, and to list background assumptions.
There are several areas of the requirements related to networking There are several areas of the requirements related to networking
aspects which are incomplete, for example, interaction with host and aspects which are incomplete, for example, interaction with host and
site multi-homing, use of anycast services, and so on. These issues site multi-homing, use of anycast services, and so on. These issues
should be considered in any future analysis work. should be considered in any future analysis work.
Based on the scenarios, we are able to define the signaling problem
on a more abstract level. In Section 3, we thus present a simple
conceptual model of the signaling problem. Additionally, we describe
the entities involved in signaling and typical signaling paths. In
Section 4 we list assumptions and exclusions.
2 Terminology 2 Terminology
In the area of Quality of Service (QoS) it is quite difficult and an We try to list the most often used terms in the document. However,
exercise for its own to define terminology. Nevertheless, we tried don't be to religious about it, they are not meant to prescribe any
to list the most often used terms in the draft and tried to explain solution in the document.
them. However, don't be to religious about it, they are not meant to
prescribe any thing in the draft.
NSIS Domain (ND) - Administrative domain where an NSIS protocol Resource Management Function (RMF): An abstract concept,
representing the management of resources in a domain or a node.
NSIS Domain (ND): Administrative domain where an NSIS protocol
signals for a resource or set of resources. signals for a resource or set of resources.
NSIS Entity (NE) - the function within a node, which implements an NSIS Entity (NE): The function within a node, which implements an
NSIS protocol. NSIS protocol.
NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR, NSIS Forwarder (NF): NSIS Entity on the path between a NI and NR,
which may interact with local resource management function (RMF) for which may interact with local resource management function (RMF) for
this purpose. NSIS Forwarder also propagates NSIS signaling further this purpose. NSIS Forwarder also propagates NSIS signaling further
through the network. It is responsible for interpreting the through the network. It is responsible for interpreting the
signaling carrying the user parameters, optionally inserting or signaling carrying the user parameters, optionally inserting or
modifying the parameters according to domain network management modifying the parameters according to domain network management
policy. policy.
NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for NSIS Initiator (NI): NSIS Entity that initiates NSIS signaling for a
a network resource based on user or application requirements. This network resource based on user or application requirements. This can
can be located in the end system, but may reside elsewhere in be located in the end system, but may reside elsewhere in network.
network.
NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well. can optionally interact with applications as well.
Resource Management Function (RMF) - an abstract concept, Flow: A traffic stream (sequence of IP packets between two end
representing the management of resources in a domain or a node. systems) for which a specific packet level treatment is provided.
The flow can be unicast (uni- or bi-directional) or multicast.
Egress point: the router via which a path exits a domain/subdomain.
End Host: the end system or host, for whose flows QoS is being
requested and provisioned.
End-to-End QoS: the QoS delivered by the network between two
communicating end hosts. End-to-end QoS co-ordinates and enforces
predefined traffic management policies across multiple network
entities and administrative domains.
Edge-to-edge QoS: QoS within an administrative domain that connects
to other networks rather than hosts or end systems.
Flow: a traffic stream (sequence of IP packets between two end
systems) for which a specific level of QoS is to be provided. The
flow can be unicast (uni- or bi-directional) or multicast.
Higher Layers: the higher layer (transport protocol and application)
functions that request QoS from the network layer. The request might
be a trigger generated within the end system, or the trigger might
be provided by some entity within the network (e.g. application
proxy or policy server).
Indication: feedback from QoS provisioning to indicate the current
QoS being provided to a flow or aggregate, and whether any
violations have been detected by the QoS technology is being used
within the local domain/subdomain.
Ingress point: the router via which a path enters a Higher Layers: The higher layer (transport protocol and application)
domain/subdomain. functions that request QoS or any other service from the network
layer. The request might be a trigger generated within the end
system, or the trigger might be provided by some entity within the
network (e.g. application proxy or policy server).
Path: the route across the networks taken by a flow or aggregate, Path: the route across the networks taken by a flow or aggregate,
i.e. which domains/subdomains it passes through and the i.e. which domains/subdomains it passes through and the
egress/ingress points for each. egress/ingress points for each.
Path segment: the segment of a path within a single Path Segment: The segment of a path within a single
domain/subdomain. domain/subdomain.
Control Information: the information the governs for instance the Control Information: the information the governs for instance the
QoS treatment to be applied to a flow or aggregate, including the QoS treatment to be applied to a flow or aggregate, including the
service class, flow administration, and any associated security or service class, flow administration, and any associated security or
accounting information. accounting information.
QoS Provisioning: the act of actually allocating resources to a flow Provisioning: the act of actually allocating resources to a flow or
or aggregate of flows, may include mechanisms such as LSP initiation aggregate of flows, may include mechanisms such as LSP initiation
for MPLS, packet scheduler configuration within a router, and so on. for MPLS, packet scheduler configuration within a router, and so on.
The mechanisms depend on the overall QoS technology being used The mechanisms depend on the overall technology and application
within the domain. being used within the domain.
Subdomain: a network within an administrative domain using a uniform Subdomain: a network within an administrative domain using a uniform
technology, e.g., a single QoS provisioning function to provision technology, e.g., a single QoS provisioning function to provision
resources. resources.
QoS Technology: a generic term for a set of protocols, standards and QoS Technology: a generic term for a set of protocols, standards and
mechanisms that can be used within a QoS domain/subdomain to manage mechanisms that can be used within a QoS domain/subdomain to manage
the QoS provided to flows or aggregates that traverse the domain. the QoS provided to flows or aggregates that traverse the domain.
Examples might include MPLS, DiffServ, and so on. A QoS technology Examples might include MPLS, DiffServ, and so on. A QoS technology
is associated with certain QoS provisioning techniques. is associated with certain QoS provisioning techniques.
skipping to change at page 6, line 38 skipping to change at page 4, line 52
the application of policies. the application of policies.
Sender-initiated signaling protocol: A sender-initiated signaling Sender-initiated signaling protocol: A sender-initiated signaling
protocol is a protocol where the NI initiates the signaling on protocol is a protocol where the NI initiates the signaling on
behalf of the sender of the data. What this means is that admission behalf of the sender of the data. What this means is that admission
control and resource allocation functions are processed from the control and resource allocation functions are processed from the
data sender towards the data receiver. However, the triggering data sender towards the data receiver. However, the triggering
instance is not specified. instance is not specified.
Receiver-initiated signaling protocol: A receiver-initiated Receiver-initiated signaling protocol: A receiver-initiated
protocol, (see e.g., RSVP [1]) is a protocol where the NSIS protocol, (see e.g., [RSVP]) is a protocol where the NSIS Responder
Responder on behalf of the receiver of the user data initiates the on behalf of the receiver of the user data initiates the
reservations. What this means is that admission control and resource reservations. What this means is that admission control and resource
allocation functions are processed from the data receiver back allocation functions are processed from the data receiver back
towards the data sender. However, the triggering instance is not towards the data sender. However, the triggering instance is not
specified. specified.
3 Problem Statement and Scope 3 Problem Statement and Scope
We provide in the following a preliminary architectural picture as a We provide in the following a preliminary architectural picture as a
basis for discussion. We will refer to it in the following basis for discussion. We will refer to it in the following
requirement section. requirement section.
A set of issues and problems to be solved has been given at a top A basic goal should be to re-use these wherever possible, and to
level by the use cases/scenarios of the appendix. However, the focus requirements work at an early stage on those areas where a new
problem of QoS has an extremely wide scope and there is a great deal solution is needed (e.g. an especially simple one). We also try to
of work already done to provide different components of the avoid defining requirements related to internal implementation
solution, such as QoS technologies for example. A basic goal should aspects.
be to re-use these wherever possible, and to focus requirements work
at an early stage on those areas where a new solution is needed
(e.g. an especially simple one). We also try to avoid defining
requirements related to internal implementation aspects.
In this section, we present a simple conceptual model of the overall
problem in order to identify the applicability to NSIS of
requirements derived from the use cases, and to clarify the scope of
the work, including any open issues. This model also identifies
further sources of requirements from external interactions with
other parts of an overall solution, clarifies the terminology used,
and allows the statement of design goals about the nature of the
solution (see section 5).
Note that this model is intended not to constrain the technical Note that this model is intended not to constrain the technical
approach taken subsequently, simply to allow concrete phrasing of approach taken subsequently, simply to allow concrete phrasing of
requirements (e.g. requirements about placement of the NSIS requirements (e.g. requirements about placement of the NSIS
Initiator, or ability to 'drive' particular QoS technologies.) Initiator.)
Roughly, the scope of NSIS is assumed to be the interaction between Roughly, the scope of NSIS is assumed to be the interaction between
the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder
including a protocol to carry the information, and the including a protocol to carry the information, and the
syntax/semantics of the information that is exchanged. Further syntax/semantics of the information that is exchanged. Further
statements on assumptions/exclusions are given in the next Section. statements on assumptions/exclusions are given in the next Section.
The main elements are: The main elements are:
1. Something that starts the request for resources, the NSIS 1. Something that starts the request for resources, the NSIS
skipping to change at page 7, line 53 skipping to change at page 5, line 54
The NSIS Forwarder does not interact with higher layers, but The NSIS Forwarder does not interact with higher layers, but
interacts with the NSIS Initiator and possibly more NSIS Forwarders interacts with the NSIS Initiator and possibly more NSIS Forwarders
on the path, edge-to-edge or possibly end-to-end. on the path, edge-to-edge or possibly end-to-end.
3. The NSIS Initiator and NSIS Forwarder(s) interact with each 3. The NSIS Initiator and NSIS Forwarder(s) interact with each
other, path segment by path segment. This interaction involves the other, path segment by path segment. This interaction involves the
exchange of data (resources control information) over some signaling exchange of data (resources control information) over some signaling
protocol. protocol.
4. The path segment traverses an underlying network covering one or 4. The path segment traverses an underlying network covering one or
more IP hops. The underlying network uses some local QoS technology. more IP hops. The underlying network might use locally different
This QoS technology has to be provisioned appropriately for the technology. For instance, QoS technology has to be provisioned
service requested. An NSIS Forwarder maps service-specific appropriately for the service requested. An NSIS Forwarder maps
information to technology-related QoS parameters and receiving service-specific information to technology-related QoS parameters
indications about success or failure in response. and receiving indications about success or failure in response.
Now concentrating more on the overall end to end (multiple domain) Now concentrating more on the overall end to end (multiple domain)
aspects, in particular: aspects, in particular:
1. The NSIS Initiator need not be located at an end system, and the 1. The NSIS Initiator need not be located at an end system, and the
NSIS Forwarders are not assumed to be located on the flow's data NSIS Forwarders are not assumed to be located on the flow's data
path. However, they must be able to identify the ingress and egress path. However, they must be able to identify the ingress and egress
points for the flow path as it traverses the domain/subdomain. Any points for the flow path as it traverses the domain/subdomain. Any
signaling protocol must be able to find the appropriate NSIS signaling protocol must be able to find the appropriate NSIS
Forwarder and carry this ingress/egress point information. Forwarder and carry this ingress/egress point information.
skipping to change at page 8, line 36 skipping to change at page 6, line 38
4. The placement of the NSIS Initiators and NSIS Forwarders is not 4. The placement of the NSIS Initiators and NSIS Forwarders is not
fixed. fixed.
4 Assumptions and Exclusions 4 Assumptions and Exclusions
4.1 Assumptions and Non-Assumptions 4.1 Assumptions and Non-Assumptions
1. The NSIS signaling could run end to end, end to edge, or edge to 1. The NSIS signaling could run end to end, end to edge, or edge to
edge, or network-to-network ((between providers), depending on what edge, or network-to-network ((between providers), depending on what
point in the network acts as the initiator, and how far towards the point in the network acts as the initiator, and how far towards the
other end of the network the signaling propagates. Although the other end of the network the signaling propagates. In general, we
figures show NSIS Forwarders at a very limited number of locations could expect NSIS Forwarders to become more 'dense' towards the
in the network (e.g. at domain or subdomain borders, or even edges of the network, but this is not a requirement. An over-
controlling a complete domain), this is only one possible case. In provisioned domain might contain no NSIS Forwarders at all (and be
general, we could expect NSIS Forwarders to become more 'dense' NSIS transparent); at the other extreme, NSIS Forwarders might be
towards the edges of the network, but this is not a requirement. An placed at every router. In the latter case, provisioning can be
over-provisioned domain might contain no NSIS Forwarders at all (and
be NSIS transparent); at the other extreme, NSIS Forwarders might be
placed at every router. In the latter case, QoS provisioning can be
carried out in a local implementation-dependent way without further carried out in a local implementation-dependent way without further
signaling, whereas in the case of remote NSIS Forwarders, a signaling, whereas in the case of remote NSIS Forwarders, a
provisioning protocol might be needed to control the routers along provisioning protocol might be needed to control the routers along
the path. This provisioning protocol is then independent of the end- the path. This provisioning protocol is then independent of the end-
to-end NSIS signaling. to-end NSIS signaling.
2. We do not consider 'pure' end-to-end signaling that is not 2. We do not consider 'pure' end-to-end signaling that is not
interpreted anywhere within the network. Such signaling is an interpreted anywhere within the network. Such signaling is an
application-layer issue and IETF protocols such as SIP etc. can be application-layer issue and IETF protocols such as SIP etc. can be
used. used.
skipping to change at page 9, line 14 skipping to change at page 7, line 13
used in each path segment. We only place requirements on the used in each path segment. We only place requirements on the
universality of the control information that is being transported. universality of the control information that is being transported.
(The goals here would be to allow the use of signaling protocols, (The goals here would be to allow the use of signaling protocols,
which are matched to the characteristics of the portion of the which are matched to the characteristics of the portion of the
network being traversed.) Note that the outcome of NSIS work might network being traversed.) Note that the outcome of NSIS work might
result in various protocols or various flavors of the same protocol. result in various protocols or various flavors of the same protocol.
This implies the need for the translation of information into domain This implies the need for the translation of information into domain
specific format as well. specific format as well.
4. We assume that the service definitions a NSIS Initiator can ask 4. We assume that the service definitions a NSIS Initiator can ask
for are known in advance of the signaling protocol running. Service for are known in advance of the signaling protocol running. For
definition includes QoS parameters, lifetime of QoS guarantee etc., instance in the QoS example, the service definition includes QoS
or any other service-specific parameters. parameters, lifetime of QoS guarantee etc., or any other service-
specific parameters.
There are many ways service requesters get to know about it. There There are many ways service requesters get to know about it. There
might be standardized services, the definition can be negotiated might be standardized services, the definition can be negotiated
together with a contract, the service definition is published at a together with a contract, the service definition is published at a
Web page, etc. Web page, etc.
5. We assume that there are means for the discovery of NSIS entities 5. We assume that there are means for the discovery of NSIS entities
in order to know the signaling peers (solutions include static in order to know the signaling peers (solutions include static
configuration, automatically discovered, or implicitly runs over the configuration, automatically discovered, or implicitly runs over the
right nodes, etc.) The discovery of the NSIS entities has security right nodes, etc.) The discovery of the NSIS entities has security
skipping to change at page 9, line 49 skipping to change at page 7, line 49
1. Development of specific mechanisms and algorithms for application 1. Development of specific mechanisms and algorithms for application
and transport layer adaptation are not considered, nor are the and transport layer adaptation are not considered, nor are the
protocols that would support it. protocols that would support it.
2. Specific mechanisms (APIs and so on) for interaction between 2. Specific mechanisms (APIs and so on) for interaction between
transport/applications and the network layer are not considered, transport/applications and the network layer are not considered,
except to clarify the requirements on the negotiation capabilities except to clarify the requirements on the negotiation capabilities
and information semantics that would be needed of the signaling and information semantics that would be needed of the signaling
protocol. The same applies to application adaptation mechanisms. protocol. The same applies to application adaptation mechanisms.
3. Specific mechanisms for QoS provisioning within a 3. Specific mechanisms for provisioning within a domain/subdomain
domain/subdomain are not considered. However, NSIS can be used for are not considered. However, NSIS can be used for signaling within a
signaling within a domain/subdomain performing QoS provisioning. It domain/subdomain performing provisioning. For instance in the QoS
should be possible to exploit these mechanisms optimally within the example, it means that the setting of QoS mechanisms in a domain is
end-to-end context. Consideration of how to do this might generate out of scope, but if we have a tunnels, NSIS could also be used for
new requirements for NSIS however. For example, the information tunnel setup with QoS guaranties. It should be possible to exploit
needed by a NSIS Forwarder to manage a radio subnetwork needs to be these mechanisms optimally within the end-to-end context.
provided by the NSIS solution. Consideration of how to do this might generate new requirements for
NSIS however. For example, the information needed by a NSIS
Forwarder to manage a radio subnetwork needs to be provided by the
NSIS solution.
4. Specific mechanisms (APIs and so on) for interaction between the 4. Specific mechanisms (APIs and so on) for interaction between the
network layer and underlying QoS provisioning mechanisms are not network layer and underlying provisioning mechanisms are not
considered. considered.
5. Interaction with resource management capabilities is not 5. Interaction with resource management capabilities is not
considered. Standard protocols should be used for this (e.g. COPS). considered. Standard protocols should be used for this (e.g. COPS).
This may imply requirements for the sort of information that should This may imply requirements for the sort of information that should
be exchanged between the NSIS entities. be exchanged between the NSIS entities.
6. Security implications related to multicasting are outside the 6. Security implications related to multicasting are outside the
scope of the signaling protocol. scope of the signaling protocol.
skipping to change at page 10, line 30 skipping to change at page 8, line 32
The protection of non-signaling messages (including data traffic The protection of non-signaling messages (including data traffic
following a reservation) is not directly considered by a signaling following a reservation) is not directly considered by a signaling
protocol. The protection of data messages transmitted along the protocol. The protection of data messages transmitted along the
provisioned path is outside the scope of a signaling protocol. provisioned path is outside the scope of a signaling protocol.
Regarding data traffic there is an interaction with accounting Regarding data traffic there is an interaction with accounting
(metering) and edge routers might require packets to be integrity (metering) and edge routers might require packets to be integrity
protected to be able to securely assign incoming data traffic to a protected to be able to securely assign incoming data traffic to a
particular user. particular user.
Additionally there might be an interaction with IPSec protected Additionally there might be an interaction with IPSec protected
traffic experiencing QoS treatment and the established state created traffic experiencing service-specific treatment and the established
due to signaling. One example of such an interaction is the different state created due to signaling. One example of such an interaction is
flow identification with and without IPSec protection. the different flow identification with and without IPSec protection.
Many security properties are likely to be application specific and Many security properties are likely to be application specific and
may be provided by the corresponding application layer protocol. may be provided by the corresponding application layer protocol.
8. Service definitions and in particular QoS classes are out of 8. Service definitions and in particular QoS services and classes
scope. Together with the service definition any definition of are out of scope. Together with the service definition any
service specific parameters are not considered in this draft. Only definition of service specific parameters are not considered in this
the base NSIS signaling protocol for transporting the service document. Only the base NSIS signaling protocol for transporting the
information are handled. service information are handled.
9. Similarly, specific methods, protocols, and ways to express 9. Similarly, specific methods, protocols, and ways to express
QoS/service information in the Application/Session level are not service information in the Application/Session level are not
considered (e.g., SDP, SIP, RTSP, etc.). considered (e.g., SDP, SIP, RTSP, etc.).
10. The specification of any extensions needed to signal information 10. The specification of any extensions needed to signal information
via application level protocols (e.g. SDP), and the mapping on NSIS via application level protocols (e.g. SDP), and the mapping on NSIS
information are considered outside of the scope of NSIS working information are considered outside of the scope of NSIS working
group, as this work is in the direct scope of other IETF working group, as this work is in the direct scope of other IETF working
groups (e.g. MMUSIC). groups (e.g. MMUSIC).
11. Handoff decision and trigger sources: An NSIS protocol is not 11. Handoff decision and trigger sources: An NSIS protocol is not
used to trigger handoffs in mobile IP, nor is it used to decide used to trigger handoffs in mobile IP, nor is it used to decide
whether to handoff or not. As soon as or in some situation even whether to handoff or not. As soon as or in some situation even
before a handoff happened, an NSIS protocol might be used for before a handoff happened, an NSIS protocol might be used for
signaling for QoS again. However, NSIS MUST interwork with several signaling for the particular service again. The basic underlying
assumption is that the route comes first (defining the path) and the
signaling comes after it (following the path). This doesn't prevent
a signaling application at some node interacting with something that
modifies the path, but the requirement is then just for NSIS to live
with that possibility. However, NSIS must interwork with several
protocols for mobility management. protocols for mobility management.
12. QoS monitoring is out of scope. It is heavily dependent on the 12. Service monitoring is out of scope. It is heavily dependent on
type of the application and or transport service, and in what the type of the application and or transport service, and in what
scenario it is used. scenario it is used.
5 Requirements 5 Requirements
This section defines more detailed requirements for a signaling This section defines more detailed requirements for a signaling
solution, derived from consideration of the use cases/scenarios solution, derived from consideration of the use cases/scenarios
described in the appendix, and respecting the framework, scoping described in the appendix, and respecting the framework, scoping
assumptions, and terminology considered earlier. The requirements assumptions, and terminology considered earlier. The requirements
are in subsections, grouped roughly according to general technical are in subsections, grouped roughly according to general technical
aspects: architecture and design goals, topology issues, parameters, aspects: architecture and design goals, topology issues, parameters,
performance, security, information, and flexibility. performance, security, information, and flexibility.
Two general (and potentially contradictory) goals for the solution Two general (and potentially contradictory) goals for the solution
are that it should be applicable in a very wide range of scenarios, are that it should be applicable in a very wide range of scenarios,
and at the same time lightweight in implementation complexity and and at the same time lightweight in implementation complexity and
resource requirements in nodes. One approach to this is that the resource requirements in nodes. One approach to this is that the
solution could deal with certain requirements via modular components solution could deal with certain requirements via modular components
or capabilities, which are optional to implement in individual or capabilities, which are optional to implement in individual
nodes. nodes.
Some of the requirements are technically contradictory. Depending on
the scenarios a solution applies to, one or the other requirement is
applicable.
In order to prioritize the various requirements we define different In order to prioritize the various requirements we define different
'parts of the network'. In the different parts of the network a 'parts of the network'. In the different parts of the network a
particular requirement might have a different priority. particular requirement might have a different priority.
The parts of the networks we differentiate are the host-to-first The parts of the networks we differentiate are the host-to-first
router, the access network, and the core network. The host to first router, the access network, and the core network. The host to first
router part includes all the layer 2 technologies to access to the router part includes all the layer 2 technologies to access to the
Internet. In many cases, there is an application and/or user running Internet. In many cases, there is an application and/or user running
on the host initiating signaling. The access network can be on the host initiating signaling. The access network can be
characterized by low capacity links, medium speed IP processing characterized by low capacity links, medium speed IP processing
capabilities, and it might consist of a complete layer 2 network as capabilities, and it might consist of a complete layer 2 network as
well. The core network characteristics include high-speed forwarding well. The core network characteristics include high-speed forwarding
capacities and inter-domain issues. All of them are not strictly capacities and inter-domain issues. These divisions between network
defined and should not be regarded as that, but should give a types are not strict and do not appear in all networks, but where
feeling about where in the network we have different requirements they do exist they may influence signaling requirements and will be
concerning signaling. highlighted as necessary.
5.1 Architecture and Design Goals 5.1 Architecture and Design Goals
This section contains requirements related to desirable overall This section contains requirements related to desirable overall
characteristics of a solution, e.g. enabling flexibility, or characteristics of a solution, e.g. enabling flexibility, or
independence of parts of the framework. independence of parts of the framework.
5.1.1 MUST be applicable for different technologies. 5.1.1 MUST be applicable for different technologies.
The signaling protocol MUST work with various QoS technologies as The signaling protocol MUST work with various QoS and non-QoS
well as other technologies needing signaling. The information technologies. The basic information exchanged over the signaling
exchanged over the signaling protocol must be in such detail and protocol MUST be in such detail and quantity that it is useful for
quantity that it is useful for various technologies. various technologies.
5.1.2 Resource availability information on request 5.1.2 SHOULD provide resource availability information on request
In some scenarios, e.g., the mobile terminal scenario, it is NSIS SHOULD provide a mechanism to check whether resources are
required to query, whether resources are available, without available without performing a reservation. In some scenarios, e.g.,
performing a reservation on the resource. One solution might be a the mobile terminal scenario, it is required to query, whether
feedback mechanism based on which a QoS inferred handover can take resources are available, without performing a reservation on the
place. So NSIS SHOULD provide a mechanism to check whether resources resource.
are available without performing a reservation
5.1.3 NSIS MUST be designed modular 5.1.3 NSIS MUST be designed modular
A modular design allows for more lightweight implementations, if A modular design allows for more lightweight implementations, if
fewer features are needed. Mutually exclusive solutions are fewer features are needed. Mutually exclusive solutions are
supported. Examples for modularity: supported. Examples for modularity:
- Work over any kind of network (narrowband versus broadband, error- - Work over any kind of network (narrowband versus broadband, error-
prone versus reliable, ...). This implies low bandwidth signaling prone versus reliable, ...). This implies low bandwidth signaling
and redundant information MUST be supported if necessary. and redundant information MUST be supported if necessary.
skipping to change at page 12, line 48 skipping to change at page 10, line 52
development of these two aspects of the solution, and allows for development of these two aspects of the solution, and allows for
this control information to be carried within other protocols, this control information to be carried within other protocols,
including application layer ones, existing ones or those being including application layer ones, existing ones or those being
developed in the future. The gained flexibility in the information developed in the future. The gained flexibility in the information
transported allows for the applicability of the same protocol in transported allows for the applicability of the same protocol in
various scenarios. various scenarios.
However, note that the information carried needs to be the However, note that the information carried needs to be the
standardized; otherwise interoperability is difficult to achieve. standardized; otherwise interoperability is difficult to achieve.
5.1.5 NSIS MUST reuse existing QoS provisioning 5.1.5 NSIS MUST reuse existing provisioning
Reuse existing functions and protocols for QoS provisioning within a Reuse existing functions and protocols for provisioning within a
domain/subdomain unchanged. (Motivation: 'Don't re-invent the domain/subdomain unchanged. (Motivation: 'Don't re-invent the
wheel'.) wheel'.)
5.1.6 Independence of signaling and provisioning paradigm 5.1.6 Independence of signaling and provisioning paradigm
The signaling MUST be independent of the paradigm and mechanism of The signaling MUST be independent of the paradigm and mechanism of
provisioning. E.g., in the case of signaling for QoS, the provisioning. E.g., in the case of signaling for QoS, the
independence of the signaling protocol from the QoS provisioning independence of the signaling protocol from the QoS provisioning
allows for using the NSIS protocol together with various QoS allows for using the NSIS protocol together with various QoS
technologies in various scenarios. technologies in various scenarios.
5.1.7 Application independence 5.1.7 Application independence
The signaling protocol MUST be independent of the application. The The signaling protocol MUST be independent of the application. The
control information SHOULD be application independent, because we control information SHOULD be application independent, because we
look into network level signaling. look into network level signaling.
The requirement relates to the way the signaling interacts with The requirement relates to the way the signaling interacts with
upper layer functions (users, applications, and QoS administration), upper layer functions (users, applications, and QoS administration),
and lower layer QoS technologies. and lower layer technologies.
Opaque application information MAY get transported in the signaling Opaque application information MAY get transported in the signaling
message, without being handled in the network. Development and message, without being handled in the network. Development and
deployment of new applications SHOULD be possible without impacting deployment of new applications SHOULD be possible without impacting
the network infrastructure. the network infrastructure.
5.2 Signaling Flows 5.2 Signaling Flows
This section contains requirements related to the possible signaling This section contains requirements related to the possible signaling
flows that should be supported, e.g. over what parts of the flow flows that should be supported, e.g. over what parts of the flow
skipping to change at page 14, line 12 skipping to change at page 12, line 16
resources and the signaling will be used as a tool for resource resources and the signaling will be used as a tool for resource
management. For various reasons (such as efficient use of expensive management. For various reasons (such as efficient use of expensive
bandwidth), one will want to have fine-grained, fast, and very bandwidth), one will want to have fine-grained, fast, and very
dynamic control of the resources in the network. dynamic control of the resources in the network.
There are going to be cases where there will be neither signaling There are going to be cases where there will be neither signaling
nor a centralized entity (over-provisioning). Nothing has to be done nor a centralized entity (over-provisioning). Nothing has to be done
anyway. anyway.
One can capture the requirement with the following, different One can capture the requirement with the following, different
wording: If one views the domain with a QoS technology as a virtual wording: If one views the domain as a virtual router then NSIS
router then NSIS signaling used between those virtual routers MUST signaling used between those virtual routers MUST follow the same
follow the same path as the data. path as the data.
Routing the signaling protocol along an independent path is desired Routing the signaling protocol along an independent path is desired
by network operators/designers. Ideally, the capability to route the by network operators/designers. Ideally, the capability to route the
protocol along an independent path would give the network protocol along an independent path would give the network
designer/operator the option to manage bandwidth utilization through designer/operator the option to manage bandwidth utilization through
the topology. the topology.
There are other possibilities as well. An NSIS protocol MUST accept There are other possibilities as well. An NSIS protocol MUST accept
all of these possibilities with a strong focus on the on-path all of these possibilities with a strong focus on the on-path
signaling. signaling.
5.2.3 Concealment of topology and technology information 5.2.3 Concealment of topology and technology information
The NSIS protocol SHOULD allow for hiding the internal structure of The NSIS protocol SHOULD allow for hiding the internal structure of
a NSIS domain from end-nodes and from other networks. Hence an a NSIS domain from end-nodes and from other networks. Hence an
adversary should not be able to learn the internal structure of a adversary should not be able to learn the internal structure of a
network with the help of the signaling protocol. network with the help of the signaling protocol.
In various scenarios, topology information SHOULD be hidden for In various scenarios, topology information should be hidden for
various reasons. From a business point of view, some administrations various reasons. From a business point of view, some administrations
don't want to reveal the topology and technology used. don't want to reveal the topology and technology used.
5.2.4 Transparency of signaling to network 5.2.4 Transparency of signaling to network
It SHOULD be possible that the signaling for some flows traverse It SHOULD be possible that the signaling for some flows traverse
path segments transparently, i.e., without interpretation at NSIS path segments transparently, i.e., without interpretation at NSIS
Forwarders within the network. An example would be a subdomain Forwarders within the network. An example would be a subdomain
within a core network, which only interpreted signaling for within a core network, which only interpreted signaling for
aggregates established at the domain edge, with the flow-related aggregates established at the domain edge, with the flow-related
signaling passing transparently through it. signaling passing transparently through it.
In other words, NSIS SHOULD work in hierarchical scenarios, where In other words, NSIS SHOULD work in hierarchical scenarios, where
big pipes/trunks are setup using NSIS signaling, but also flows big pipes/trunks are setup using NSIS signaling, but also flows
which run within that big pipe/trunk are setup using NSIS. which run within that big pipe/trunk are setup using NSIS.
5.3 Additional information beyond signaling for a service 5.3 Messaging
5.3.1 Explicit release of resources 5.3.1 Explicit release of resources
When a resource reservation is no longer necessary, e.g. because the When a resource reservation is no longer necessary, e.g. because the
application terminates, or because a mobile host experienced a hand- application terminates, or because a mobile host experienced a hand-
off, it MUST be possible to explicitly release resources. In general off, it MUST be possible to explicitly release resources. In general
explicit release enhances the overall network utilization. explicit release enhances the overall network utilization.
5.3.2 Possibility for automatic release of resources after failure 5.3.2 Possibility for automatic release of resources after failure
When the NSIS Initiator goes down, the resources it requested in the When the NSIS Initiator goes down, the resources it requested in the
network SHOULD be released, since they will no longer be necessary. network SHOULD be released, since they will no longer be necessary.
skipping to change at page 15, line 28 skipping to change at page 13, line 30
The goal is to prevent stale state within the network and adds The goal is to prevent stale state within the network and adds
robustness to the operation of NSIS. So in other words, an NSIS robustness to the operation of NSIS. So in other words, an NSIS
signaling protocol or mechanisms MUST provide means for an NSIS signaling protocol or mechanisms MUST provide means for an NSIS
entity to discover and remove local stale state. entity to discover and remove local stale state.
Note that this might need to work together with a notification Note that this might need to work together with a notification
mechanism. mechanism.
5.3.3 Notifications sent upstream 5.3.3 Notifications sent upstream
NSIS Forwarders SHOULD be able to notify the NSIS Initiator or any NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS
other NSIS Forwarder upstream, if there is a state change inside the Forwarder upstream, if there is a state change inside the network.
network. There are various types of network changes for instance There are various types of network changes for instance among them:
among them:
Recoverable errors: the network nodes can locally repair this type Recoverable errors: the network nodes can locally repair this type
error. The network nodes do not have to notify the users of the error. The network nodes do not have to notify the users of the
error immediately. This is a condition when the danger of error immediately. This is a condition when the danger of
degradation (or actual short term degradation) of the provided QoS degradation (or actual short term degradation) of the provided
was overcome by the network (NSIS Forwarder) itself. service was overcome by the network (NSIS Forwarder) itself.
Unrecoverable errors: the network nodes cannot handle this type of Unrecoverable errors: the network nodes cannot handle this type of
error, and have to notify the users as soon as possible. error, and have to notify the users as soon as possible.
QoS degradation/severe congestion: In case the service cannot be Service degradation/severe congestion: In case the service cannot be
provided completely but partially only. provided completely but partially only.
Repair indication: If an error occurred and it has been fixed, this Repair indication: If an error occurred and it has been fixed, this
triggers the sending of a notification. triggers the sending of a notification.
Service upgrade available: If a previously requested better service Service upgrade available: If a previously requested better service
becomes available. becomes available.
The content of the notification is very service specific, but it is The content of the notification is very service specific, but it is
must at least carry type information. Additionally, it may carry the must at least carry type information. Additionally, it may carry the
skipping to change at page 16, line 20 skipping to change at page 14, line 24
notification. E.g., if it gets an error notification it might notification. E.g., if it gets an error notification it might
teardown the reservation, even if everything is ok. So the teardown the reservation, even if everything is ok. So the
notification might depend on security associations between the notification might depend on security associations between the
sender of the notification and its receiver. If a hop-by-hop sender of the notification and its receiver. If a hop-by-hop
security mechanism is chosen, this implies also that notifications security mechanism is chosen, this implies also that notifications
need to be sent on the reverse path. need to be sent on the reverse path.
5.3.4 Feedback about success of service request 5.3.4 Feedback about success of service request
A request for service MUST be answered at least with yes or no. A request for service MUST be answered at least with yes or no.
However, it MAY be useful in case of a negative answer to also get a However, it may be useful in case of a negative answer to also get a
description of what amount of resources a request is possible. So an description of what amount of resources a request is possible. So an
opaque element MAY be included into the answer. The element heavily opaque element MAY be included into the answer. The element heavily
depends on the service requested. depends on the service requested.
5.3.5 Local information exchange 5.3.5 Local information exchange
The signaling protocol MUST be able to exchange local information The signaling protocol MUST be able to exchange local information
between NSIS Forwarders located within one single administrative between NSIS Forwarders located within one single administrative
domain. Local information might, for example, be IP addresses, domain. Local information might, for example, be IP addresses,
severe congestion notification, notification of successful or severe congestion notification, notification of successful or
skipping to change at page 17, line 6 skipping to change at page 15, line 9
changed in a non-recoverable way. The NSIS initiator SHOULD be able changed in a non-recoverable way. The NSIS initiator SHOULD be able
to control what is requested end to end, without the request being to control what is requested end to end, without the request being
gradually mutated as it passes through a sequence of domains. This gradually mutated as it passes through a sequence of domains. This
implies that in case of changes made on the parameters, the original implies that in case of changes made on the parameters, the original
requested ones must still be available. requested ones must still be available.
Note that we do not require anything about particular parameters Note that we do not require anything about particular parameters
being changed. being changed.
Additionally, note that a provider or that particular services Additionally, note that a provider or that particular services
requested, can still influence the QoS provisioning but in the requested, can still influence the provisioning but in the signaling
signaling message the request should stay the same. message the request should stay the same.
5.4.2 Possibility to add and remove local domain information 5.4.2 Possibility to add and remove local domain information
It SHOULD be possible for the Resource Management Function to add It SHOULD be possible for the Resource Management Function to add
and remove local scope elements. E.g., at the entrance to a domain and remove local scope elements. E.g., at the entrance to a domain
domain-specific information is added, which is used in this domain domain-specific information is added, which is used in this domain
only, and the information is removed again when a signaling message only, and the information is removed again when a signaling message
leaves the domain. The motivation is in the economy of re-use the leaves the domain. The motivation is in the economy of re-use the
protocol for domain internal signaling of various information protocol for domain internal signaling of various information
pieces. Where additional information is needed within a particular pieces. Where additional information is needed within a particular
domain, it should be possible to carry this at the same time as the domain, it should be possible to carry this at the same time as the
end-to-end information. end-to-end information.
5.4.3 Independence of reservation identifier 5.4.3 Independence of reservation identifier
A reservation identifier, which is independent of the flow A reservation identifier MUST be independent of the flow identifier
identifier (flow end-points), MUST be used. Various scenarios in the (flow end-points). Various scenarios in the mobility area require
mobility area require this independence because flows resulting from this independence because flows resulting from handoff might have
handoff might have changed end-points etc. but still have the same changed end-points etc. but still have the same service requirement.
service requirement. Also several proxy-based signaling methods Also several proxy-based signaling methods profit from such as
might profit from such as independence. independence.
5.4.4 Seamless modification of already reserved resources 5.4.4 Seamless modification of already reserved resources
In many case, the reservation needs to be updated (up or downgrade). In many case, the reservation needs to be updated (up or downgrade).
This SHOULD happen seamlessly without service interruption. At least This SHOULD happen seamlessly without service interruption. At least
the signaling protocol should allow for it, even if some data path the signaling protocol should allow for it, even if some data path
elements might not be capable of doing so. elements might not be capable of doing so.
5.4.5 Grouping of signaling for several micro-flows 5.4.5 Grouping of signaling for several micro-flows
skipping to change at page 19, line 16 skipping to change at page 17, line 18
are only examples, include message aggregation, by ignoring are only examples, include message aggregation, by ignoring
signaling message, header compression, or minimizing functionality. signaling message, header compression, or minimizing functionality.
The framework may choose any method as long as the requirement is The framework may choose any method as long as the requirement is
met. met.
5.5.5 Highest possible network utilization 5.5.5 Highest possible network utilization
There are networking environments that require high network There are networking environments that require high network
utilization for various reasons, and the signaling protocol SHOULD utilization for various reasons, and the signaling protocol SHOULD
to its best ability support high resource utilization while to its best ability support high resource utilization while
maintaining appropriate QoS. maintaining appropriate service quality.
In networks where resources are very expensive (as is the case for In networks where resources are very expensive (as is the case for
many wireless networks), efficient network utilization is of many wireless networks), efficient network utilization is of
critical financial importance. On the other hand there are other critical financial importance. On the other hand there are other
parts of the network where high utilization is not required. parts of the network where high utilization is not required.
5.6 Flexibility 5.6 Flexibility
This section lists the various ways the protocol can flexibly be This section lists the various ways the protocol can flexibly be
employed. employed.
skipping to change at page 19, line 42 skipping to change at page 17, line 44
5.6.2 Flexibility in the placement of the NSIS Initiator 5.6.2 Flexibility in the placement of the NSIS Initiator
NSIS MUST be flexible in placing an NSIS Initiator. The NSIS NSIS MUST be flexible in placing an NSIS Initiator. The NSIS
Initiator might be the sender or the receiver of content. But also Initiator might be the sender or the receiver of content. But also
network-initiated reservations MUST be available in various network-initiated reservations MUST be available in various
scenarios such as PSTN gateways, some VPNs, and mobility. scenarios such as PSTN gateways, some VPNs, and mobility.
5.6.3 Flexibility in the initiation of re-negotiation 5.6.3 Flexibility in the initiation of re-negotiation
The sender or the receiver of content SHOULD be able to initiate a The NSIS Initiator or the NSIS Responder SHOULD be able to initiate
re-negotiation or change the reservation due to various reasons, a re-negotiation or change the reservation due to various reasons,
such as local resource shortage (CPU, memory on end-system) or a such as local resource shortage (CPU, memory on end-system) or a
user changed application preference/profiles. But also network- user changed application preference/profiles.
initiated re-negotiation SHOULD be supported in cases, where the
network is not able to further guarantee resources etc.
5.6.4 Uni / bi-directional reservation 5.6.4 SOULD support network-initiated re-negotiation
NSIS SHOULD support network-initiated re-negotiation. This is used
in cases, where the network is not able to further guarantee
resources and want to e.g. downgrade a reservation.
5.6.5 Uni / bi-directional reservation
Both unidirectional as well as bi-direction reservations SHOULD be Both unidirectional as well as bi-direction reservations SHOULD be
possible. With bi-directional reservations we mean here reservations possible. With bi-directional reservations we mean here reservations
having the same end-points. But the path in the two directions does having the same end-points. But the path in the two directions does
not need to be the same. not need to be the same.
The goal of a bi-directional reservation is mainly an optimization The goal of a bi-directional reservation is mainly an optimization
in terms of setup delay. There is no requirements on constrains such in terms of setup delay. There is no requirements on constrains such
as use the same data path etc. as use the same data path etc.
5.7 Security 5.7 Security
This section discusses security-related requirements. For a This section discusses security-related requirements. For a
discussion of security threats see [3]. The NSIS protocol MUST discussion of security threats see [SEC-THR]. The NSIS protocol MUST
provide means for security, but it MUST be allowed that nodes provide means for security, but it MUST be allowed that nodes
implementing NSIS signaling do not need use the security means. implementing NSIS signaling do not need use the security means.
5.7.1 Authentication of signaling requests 5.7.1 Authentication of signaling requests
A signaling protocol MUST make provision for enabling various A signaling protocol MUST make provision for enabling various
entities to be authenticated against each other using strong entities to be authenticated against each other using strong
authentication mechanisms. The term strong authentication points to authentication mechanisms. The term strong authentication points to
the fact that weak plain-text password mechanisms must not be used the fact that weak plain-text password mechanisms must not be used
for authentication. for authentication.
skipping to change at page 20, line 52 skipping to change at page 18, line 56
adversary from modifying parts of the signaling message and from adversary from modifying parts of the signaling message and from
mounting denial of service or theft of service type of attacks mounting denial of service or theft of service type of attacks
against network elements participating in the protocol execution. against network elements participating in the protocol execution.
5.7.4 Replay protection 5.7.4 Replay protection
To prevent replay of previous signaling messages the signaling To prevent replay of previous signaling messages the signaling
protocol MUST provide means to detect old i.e. already transmitted protocol MUST provide means to detect old i.e. already transmitted
signaling messages. A solution must cover issues of synchronization signaling messages. A solution must cover issues of synchronization
problems in the case of a restart or a crash of a participating problems in the case of a restart or a crash of a participating
network element. The use of replay mechanism apart from sequence network element.
numbers should be investigated.
5.7.5 Hop-by-hop security 5.7.5 Hop-by-hop security
Hop-by-Hop security SHOULD be supported. It is a well known and Hop-by-Hop security SHOULD be supported. It is a well known and
proven concept in Quality-of-Service and other signaling protocols proven concept in Quality-of-Service and other signaling protocols
that allows intermediate nodes that actively participate in the that allows intermediate nodes that actively participate in the
protocol to modify the messages as it is required by processing rule. protocol to modify the messages as it is required by processing rule.
Note that this requirement does not exclude end-to-end or network-to- Note that this requirement does not exclude end-to-end or network-to-
network security of a signaling message. End-to-end security between network security of a signaling message. End-to-end security between
the initiator and the responder may be used to provide protection of the initiator and the responder may be used to provide protection of
skipping to change at page 21, line 22 skipping to change at page 19, line 27
5.7.6 Identity confidentiality and location privacy 5.7.6 Identity confidentiality and location privacy
Identity confidentiality SHOULD be supported. It enables privacy and Identity confidentiality SHOULD be supported. It enables privacy and
avoids profiling of entities by adversary eavesdropping the signaling avoids profiling of entities by adversary eavesdropping the signaling
traffic along the path. The identity used in the process of traffic along the path. The identity used in the process of
authentication may also be hidden to a limited extent from a network authentication may also be hidden to a limited extent from a network
to which the initiator is attached. However the identity MUST provide to which the initiator is attached. However the identity MUST provide
enough information for the nodes in the access network to collect enough information for the nodes in the access network to collect
accounting data. accounting data.
Location privacy MAY be supported. It is an issue for the initiator Location privacy MAY be supported. It is an issue for the initiator
who triggers the signaling protocol. In some scenarios the initiator who triggers the signaling protocol. In some scenarios the initiator
may not be willing to reveal location information to the responder as may not be willing to reveal location information to the responder as
part the signaling procedure. part the signaling procedure.
5.7.7 Denial-of-service attacks 5.7.7 Denial-of-service attacks
A signaling protocol SHOULD provide prevention of DoS attacks. A signaling protocol SHOULD provide prevention of Denial-of-service
To effectively prevent denial-of-service attacks it is necessary that attacks. To effectively prevent denial-of-service attacks it is
the used security and protocol mechanisms MUST have low computation necessary that the used security and protocol mechanisms MUST have
complexity to verify a resource request prior authenticating the low computation complexity to verify a resource request prior
requesting entity. Additionally the signaling protocol and the used authenticating the requesting entity. Additionally the signaling
security mechanisms SHOULD NOT require large resource consumption protocol and the used security mechanisms SHOULD NOT require large
(for example main memory or other additional message exchanges) resource consumption (for example main memory or other additional
before a successful authentication was done. message exchanges) before a successful authentication was done.
5.7.8 Confidentiality of signaling messages 5.7.8 Confidentiality of signaling messages
Based on the signaling information exchanged between nodes Based on the signaling information exchanged between nodes
participating in the signaling protocol an adversary may learn both participating in the signaling protocol an adversary may learn both
the identities and the content of the signaling messages. To prevent the identities and the content of the signaling messages. To prevent
this from happening, confidentiality of the signaling message in a this from happening, confidentiality of the signaling message in a
hop-by-hop manner MAY be provided. Note that the protection can be hop-by-hop manner MAY be provided. Note that the protection can be
provided on a hop-by-hop basis for most message payloads since it is provided on a hop-by-hop basis for most message payloads since it is
required that entities which actively participating in the signaling required that entities which actively participating in the signaling
skipping to change at page 22, line 44 skipping to change at page 20, line 49
signaling protocol) and although the key management protocol may be signaling protocol) and although the key management protocol may be
independent there must be a way for the signaling protocol to access independent there must be a way for the signaling protocol to access
and use available (i.e. already established) security associations to and use available (i.e. already established) security associations to
avoid executing a separate key management protocol (or instance of avoid executing a separate key management protocol (or instance of
the same protocol) for protocols that closely operate together. If no the same protocol) for protocols that closely operate together. If no
such security association exists then there SHOULD be means for the such security association exists then there SHOULD be means for the
signaling protocol to dynamically trigger such a protocol. signaling protocol to dynamically trigger such a protocol.
5.8 Mobility 5.8 Mobility
5.8.1 Allow efficient QoS re-establishment after handover 5.8.1 Allow efficient service re-establishment after handover
Handover is an essential function in wireless networks. After Handover is an essential function in wireless networks. After
handover, the reservation may need to be completely or partially re- handover, the reservation may need to be completely or partially re-
established due to route changes. The re-establishment may be established due to route changes. The re-establishment may be
requested by the mobile node itself or triggered by the access point requested by the mobile node itself or triggered by the access point
that the mobile node is attached to. In the first case, the that the mobile node is attached to. In the first case, the
signaling MUST allow efficient re-establishment after handover. Re- signaling MUST allow efficient re-establishment after handover. Re-
establishment after handover MUST be as quick as possible so that establishment after handover MUST be as quick as possible so that
the mobile node does not experience service interruption or service the mobile node does not experience service interruption or service
degradation. The re-establishment SHOULD be localized, and not degradation. The re-establishment SHOULD be localized, and not
skipping to change at page 23, line 28 skipping to change at page 21, line 31
5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6
5.9.3 MUST be independent from charging model 5.9.3 MUST be independent from charging model
Signaling MUST NOT be constrained by charging models or the charging Signaling MUST NOT be constrained by charging models or the charging
infrastructure used. infrastructure used.
5.9.4 SHOULD provide hooks for AAA protocols 5.9.4 SHOULD provide hooks for AAA protocols
The security mechanism SHOULD be developed with respect to be able The NSIS SHOULD be developed with respect to be able to collect
to collect usage records from one or more network elements. usage records from one or more network elements.
5.9.5 SHOULD interwork with seamless handoff protocols 5.9.5 SHOULD interwork with seamless handoff protocols
An NSIS protocol SHOULD interwork with seamless handoff protocols An NSIS protocol SHOULD interwork with seamless handoff protocols
such as context transfer and candidate access router (CAR) such as context transfer and candidate access router (CAR)
discovery. The goal to achieve is that signaling works fast enough discovery.
in case of a handoff, where that protocols might help in one way or
the other.
5.9.6 MAY interwork with non-traditional routing 5.9.6 MAY interwork with non-traditional routing
NSIS assumes traditional routing, but networks, which do non- NSIS assumes traditional routing, but networks, which do non-
traditional L3 routing, should not break it. traditional L3 routing, should not break it.
5.10 Operational 5.10 Operational
5.10.1 Ability to assign transport quality to signaling messages. 5.10.1 Ability to assign transport quality to signaling messages.
skipping to change at page 24, line 30 skipping to change at page 22, line 32
NSIS peers SHOULD be able to detect the malfunctioning peer. It may NSIS peers SHOULD be able to detect the malfunctioning peer. It may
notify the NSIS Initiator or another NSIS entity involved in the notify the NSIS Initiator or another NSIS entity involved in the
signaling process. The NSIS peer may handle the problem itself e.g. signaling process. The NSIS peer may handle the problem itself e.g.
switching to a backup NSIS entity. In the latter case note that switching to a backup NSIS entity. In the latter case note that
synchronization of state between the primary and the backup entity synchronization of state between the primary and the backup entity
is needed. is needed.
6 Security Considerations 6 Security Considerations
Section 5.8 of this draft provides security related requirements of Section 5.7 of this document provides security related requirements
a signaling protocol. Another document describes security threads of a signaling protocol. A separate document describes security
for NSIS [3]. threats for NSIS signaling [SEC-THR].
7 Reference 7 References
[1] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S., [SEC-THR] Tschofenig, H., "NSIS Threats", Internet Draft <draft-
ietf-nsis-threats-00.txt>, October 2002.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[2] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
"RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
2001. December 2001.
[3] Tschofenig, H., "NSIS Threats", <draft-tschofenig-nsis-threats-
00.txt>, May 2002.
8 Acknowledgments 8 Acknowledgments
Quite a number of people have been involved in the discussion of the Quite a number of people have been involved in the discussion of the
draft, adding some ideas, requirements, etc. We list them without a document, adding some ideas, requirements, etc. We list them without
guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
(NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
University Berlin), Xiaoming Fu (Technical University Berlin), Hans- University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya
Freytsis. Freytsis.
Some text and/or ideas for text, requirements, scenarios have been Some text and/or ideas for text, requirements, scenarios have been
taken from a draft written by the following authors: David Partain taken from an Internet Draft written by the following authors: David
(Ericsson), Anders Bergsten (Telia Research), Marc Greis (Nokia), Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis
Georgios Karagiannis (Ericsson), Jukka Manner (University of (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University
Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
actively contributed new text to the draft as well. actively contributed new text to this document as well.
Another draft impacting this draft has been written by Sven Van den Another Internet Draft impacting this document has been written by
Bosch, Maarten Buchli, and Danny Goderis. These people contributed Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel).
also with new text. These people contributed also new text.
9 Author's Addresses 9 Author's Addresses
Marcus Brunner (Editor) Marcus Brunner (Editor)
NEC Europe Ltd. NEC Europe Ltd.
Network Laboratories Network Laboratories
Adenauerplatz 6 Kurfuersten-Anlage 34
D-69115 Heidelberg D-69115 Heidelberg
Germany Germany
E-Mail: brunner@ccrle.nec.de (contact) E-Mail: brunner@ccrle.nec.de
Robert Hancock, Eleanor Hepworth Robert Hancock
Roke Manor Research Ltd Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN Romsey, Hants, SO51 0ZN
United Kingdom United Kingdom
E-Mail: [robert.hancock|eleanor.hepworth]@roke.co.uk E-Mail: robert.hancock@roke.co.uk
Eleanor Hepworth
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
E-Mail: eleanor.hepworth@roke.co.uk
Cornelia Kappler Cornelia Kappler
Siemens AG Siemens AG
Berlin 13623 Berlin 13623
Germany Germany
E-Mail: cornelia.kappler@icn.siemens.de E-Mail: cornelia.kappler@icn.siemens.de
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
skipping to change at page 25, line 47 skipping to change at page 24, line 4
E-Mail: cornelia.kappler@icn.siemens.de E-Mail: cornelia.kappler@icn.siemens.de
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munchen 81739 Munchen
Germany Germany
Email: Hannes.Tschofenig@mchp.siemens.de Email: Hannes.Tschofenig@mchp.siemens.de
10 Appendix: Scenarios/Use cases 10 Appendix: Scenarios/Use cases
In the following we describe scenarios, which are important to In the following we describe scenarios, which are important to
cover, and which allow us to discuss various requirements. Some cover, and which allow us to discuss various requirements. Some
regard this as use cases to be covered defining the use of a QoS regard this as use cases to be covered defining the use of a
signaling protocol. signaling protocol.
10.1 Terminal Mobility 10.1 Terminal Mobility
The scenario we are looking at is the case where a mobile terminal The scenario we are looking at is the case where a mobile terminal
(MT) changes from one access point to another access point. The (MT) changes from one access point to another access point. The
access points are located in separate QoS domains. We assume Mobile access points are located in separate QoS domains. We assume Mobile
IP to handle mobility on the network layer in this scenario and IP to handle mobility on the network layer in this scenario and
consider the various extensions (i.e., IETF proposals) to Mobile IP, consider the various extensions (i.e., IETF proposals) to Mobile IP,
in order to provide 'fast handover' for roaming Mobile Terminals. in order to provide 'fast handover' for roaming Mobile Terminals.
The goal to be achieved lies in providing, keeping, and adapting the The goal to be achieved lies in providing, keeping, and adapting the
requested QoS for the ongoing IP sessions in case of handover. requested QoS for the ongoing IP sessions in case of handover.
Furthermore, the negotiation of QoS parameters with the new domain Furthermore, the negotiation of QoS parameters with the new domain
via the old connection might be needed, in order to support the via the old connection might be needed, in order to support the
different 'fast handover' proposals within the IETF. different 'fast handover' proposals within the IETF.
The entities involved in this scenario include a mobile terminal, The entities involved in this scenario include a mobile terminal,
access points, an access network manager, communication partners of access points, an access network manager, and communication partners
the MT (the other end(s) of the communication association). of the MT (the other end(s) of the communication association).
From a technical point of view, terminal mobility means changing the From a technical point of view, terminal mobility means changing the
access point of a mobile terminal (MT). However, technologies might access point of a mobile terminal (MT). However, technologies might
change in various directions (access technology, QoS technology, change in various directions (access technology, QoS technology,
administrative domain). If the access points are within one specific administrative domain). If the access points are within one specific
QoS technology (independent of access technology) we call this QoS technology (independent of access technology) we call this
intra-QoS technology handoff. In the case of an inter-QoS technology intra-QoS technology handoff. In the case of an inter-QoS technology
handoff, one changes from e.g. a DiffServ to an IntServ domain, handoff, one change from e.g. a DiffServ to an IntServ domain,
however still using the same access technology. Finally, if the however still using the same access technology. Finally, if the
access points are using different access technologies we call it access points are using different access technologies we call it
inter-technology hand-off. inter-technology hand-off.
The following issues are of special importance in this scenario: The following issues are of special importance in this scenario:
1) Handoff decision 1) Handoff decision
- The QoS management requests handoff. The QoS management can decide - The QoS management requests handoff. The QoS management can decide
to change the access point, since the traffic conditions of the new to change the access point, since the traffic conditions of the new
skipping to change at page 26, line 49 skipping to change at page 25, line 4
- The mobility management forces handoff. This can have several - The mobility management forces handoff. This can have several
reasons. The operator optimizes his network, admission is no longer reasons. The operator optimizes his network, admission is no longer
granted (e.g. emptied prepaid condition). Or another example is when granted (e.g. emptied prepaid condition). Or another example is when
the MT is reaching the focus of another base station. However, this the MT is reaching the focus of another base station. However, this
might be detected via measurements of QoS on the physical layer and might be detected via measurements of QoS on the physical layer and
is therefore out of scope of QoS signaling in IP. Note again that is therefore out of scope of QoS signaling in IP. Note again that
the MT or the network (see below) might trigger the handoff. the MT or the network (see below) might trigger the handoff.
- This scenario shows that local decisions might not be enough. The - This scenario shows that local decisions might not be enough. The
rest of the path to the other end of the communication needs to be rest of the path to the other end of the communication needs to be
considered as well. Hand-off decisions in a QoS domain, does not considered as well. Hand-off decisions in a QoS domain do not only
only depend on the local resource availability, e.g., the wireless depend on the local resource availability, e.g., the wireless part,
part, but involves the rest of the path as well. Additionally, but involve the rest of the path as well. Additionally,
decomposition of an end-to-end reservation might be needed, in order decomposition of an end-to-end reservation might be needed, in order
to change only parts of it. to change only parts of it.
2) Trigger sources 2) Trigger sources
- Mobile terminal: If the end-system QoS management identifies - Mobile terminal: If the end-system QoS management identifies
another (better-suited) access point, it will request the handoff another (better-suited) access point, it will request the handoff
from the terminal itself. This will be especially likely in the case from the terminal itself. This will be especially likely in the case
that two different provider networks are involved. Another important that two different provider networks are involved. Another important
example is when the current access point bearer disappears (e.g. example is when the current access point bearer disappears (e.g.
removing the Ethernet cable). In this case, the NSIS Initiator is removing the Ethernet cable). In this case, the NSIS Initiator is
basically located on the mobile terminal. basically located on the mobile terminal.
- Network (access network manager): Sometimes, the handoff trigger - Network (access network manager): Sometimes, the handoff trigger
will be issued from the network management to optimize the overall will be issued from the network management to optimize the overall
skipping to change at page 28, line 45 skipping to change at page 26, line 53
within the cellular system. within the cellular system.
3) Initiation of IP-level QoS negotiation. IP-level QoS re- 3) Initiation of IP-level QoS negotiation. IP-level QoS re-
negotiation may be initiated by either the End Host, or by the negotiation may be initiated by either the End Host, or by the
network, based on current network loads, which might change network, based on current network loads, which might change
depending on the location of the end host. depending on the location of the end host.
4) The networks are designed and mainly used for speech 4) The networks are designed and mainly used for speech
communication (at least so far). communication (at least so far).
Note that in comparison to the former scenario, the emphasis is much Note that in comparison to the previous scenario emphasis is much
less on the mobility aspects, because mobility is mainly handled on less on the mobility aspects, because mobility is mainly handled on
the lower layer. the lower layer.
10.3 UMTS access 10.3 UMTS access
The UMTS access scenario is shown in figure 3. The Proxy-Call State The UMTS access scenario is shown in figure 3. The Proxy-Call State
Control Function/Policy Control Function (P-CSCF/PCF) is the Control Function/Policy Control Function (P-CSCF/PCF) is the
outbound SIP proxy of the visited domain, i.e. the domain where the outbound SIP proxy of the visited domain, i.e. the domain where the
mobile user wants to set-up a call. The Gateway GPRS Support Node mobile user wants to set-up a call. The Gateway GPRS Support Node
(GGSN) is the egress router of the UMTS domain and connects the UMTS (GGSN) is the egress router of the UMTS domain and connects the UMTS
skipping to change at page 32, line 35 skipping to change at page 30, line 41
The scenario includes the signaling between access networks and core The scenario includes the signaling between access networks and core
networks in order to setup and change reservations together with networks in order to setup and change reservations together with
potential negotiation. potential negotiation.
The issues to be solved in this scenario are different from previous The issues to be solved in this scenario are different from previous
ones. ones.
1) The entity of reservation is most likely an aggregate. 1) The entity of reservation is most likely an aggregate.
2) The time scales of reservations might be different (long living 2) The time scales of reservations might be different (long living
reservations of aggregates, rarer re-negotiation). reservations of aggregates, less often re-negotiation).
3) The specification of the traffic (amount of traffic), a 3) The specification of the traffic (amount of traffic), a
particular QoS is guaranteed for, needs to be changed. E.g., in case particular QoS is guaranteed for, needs to be changed. E.g., in case
additional flows are added to the aggregate, the traffic additional flows are added to the aggregate, the traffic
specification of the flow needs to be added if it is not already specification of the flow needs to be added if it is not already
included in the aggregates specification. included in the aggregates specification.
4) The flow specification is more complex including network 4) The flow specification is more complex including network
addresses and sets of different address for the source as well as addresses and sets of different address for the source as well as
for the destination of the flow. for the destination of the flow.
skipping to change at page 33, line 48 skipping to change at page 31, line 55
There are several ways that a PSTN gateway can acquire assurances There are several ways that a PSTN gateway can acquire assurances
that a network can carry its traffic across the network. These that a network can carry its traffic across the network. These
include: include:
1. Over-provisioning a high availability network. 1. Over-provisioning a high availability network.
2. Handling admission control through some policy server 2. Handling admission control through some policy server
that has a global view of the network and its resources. that has a global view of the network and its resources.
3. Per PSTN GW pair admission control. 3. Per PSTN GW pair admission control.
4. Per call admission control (where a call is defined as 4. Per call admission control (where a call is defined as
the 5 tuple used to carry a single RTP flow). the 5-tuple used to carry a single RTP flow).
Item 1 requires no signaling at all and is therefore outside the Item 1 requires no signaling at all and is therefore outside the
scope of this working group. scope of this working group.
Item 2 is really a better informed version of 1, but it is also Item 2 is really a better informed version of 1, but it is also
outside the scope of this working group as it relies on a particular outside the scope of this working group as it relies on a particular
telephony signaling protocol rather than a packet admission control telephony signaling protocol rather than a packet admission control
protocol. protocol.
Item 3 is initially attractive, as it appears to have reasonable Item 3 is initially attractive, as it appears to have reasonable
skipping to change at page 34, line 23 skipping to change at page 32, line 31
scaling problems. The objective here is to place the requirements on scaling problems. The objective here is to place the requirements on
Item 4 such that a scalable per-flow admission control protocol or Item 4 such that a scalable per-flow admission control protocol or
protocol suite may be developed. protocol suite may be developed.
The case where per-flow signaling extends to individual IP end- The case where per-flow signaling extends to individual IP end-
points allows the inclusion of IP phones on cable, DSL, wireless or points allows the inclusion of IP phones on cable, DSL, wireless or
other access networks in this scenario. other access networks in this scenario.
Call Scenario Call Scenario
A PSTN GW signals end-to-end for some 5 tuple defined flow a A PSTN GW signals end-to-end for some 5-tuple defined flow a
bandwidth and QoS requirement. Note that the 5 tuple might include bandwidth and QoS requirement. Note that the 5-tuple might include
masking/wildcarding. The access network admits this flow according masking/wildcarding. The access network admits this flow according
to its local policy and the specific details of the access to its local policy and the specific details of the access
technology. technology.
At the edge router (i.e., border node), the flow is admitted, again At the edge router (i.e., border node), the flow is admitted, again
with an optional authentication process, possibly involving an with an optional authentication process, possibly involving an
external policy server. Note that the relationship between the PSTN external policy server. Note that the relationship between the PSTN
GW and the policy server and the routers and the policy server is GW and the policy server and the routers and the policy server is
outside the scope of NSIS. The edge router then admits the flow into outside the scope of NSIS. The edge router then admits the flow into
the core of the network, possibly using some aggregation technique. the core of the network, possibly using some aggregation technique.
At the interior nodes, the NSIS host-to-host signaling should either At the interior nodes, the NSIS host-to-host signaling should either
be ignored or invisible as the Edge router performed the admission be ignored or invisible as the Edge router performed the admission
control decision to some aggregate. control decision to some aggregate.
At the inter-provider router (i.e., border node), again the NSIS At the inter-provider router (i.e., border node), again the NSIS
host-to-host signaling should either be ignored or invisible as the host-to-host signaling should either be ignored or invisible, as the
Edge router has performed an admission control decision about an Edge router has performed an admission control decision about an
aggregate across a carrier network. aggregate across a carrier network.
10.9 PSTN trunking gateway 10.9 PSTN trunking gateway
One of the use cases for the NSIS signaling protocol is the scenario One of the use cases for the NSIS signaling protocol is the scenario
of interconnecting PSTN gateways with an IP network that supports of interconnecting PSTN gateways with an IP network that supports
QoS. QoS.
Four different scenarios are considered here. Four different scenarios are considered here.
1. In-band QoS signaling is used. In this case the Media Gateway 1. In-band QoS signaling is used. In this case the Media Gateway
(MG) will be acting as the NSIS Initiator and the Edge Router (MG) will be acting as the NSIS Initiator and the Edge Router
(ER) will be the NSIS Forwarder. Hence, the ER should do (ER) will be the NSIS Forwarder. Hence, the ER should do
admission control (into pre-provisioned traffic trunks) for the admission control (into pre-provisioned traffic trunks) for the
individual traffic flows. This scenario is not further individual traffic flows. This scenario is not further
considered here. considered here.
2. Out-of-band signaling in a single domain, the NSIS forwarder is
2. Out-of-band signaling in a single domain, the NSIS Forwarder is
integrated in the MGC. In this case no NSIS protocol is integrated in the MGC. In this case no NSIS protocol is
required. required.
3. Out-of-band signaling in a single domain, the NSIS Forwarder is 3. Out-of-band signaling in a single domain, the NSIS forwarder is
a separate box. In this case NSIS signaling is used between the a separate box. In this case NSIS signaling is used between the
MGC and the NSIS Forwarder. MGC and the NSIS Forwarder.
4. Out-of-band signaling between multiple domains, the NSIS 4. Out-of-band signaling between multiple domains, the NSIS
Forwarder (which may be integrated in the MGC) triggers the Forwarder (which may be integrated in the MGC) triggers the
NSIS Forwarder of the next domain. NSIS Forwarder of the next domain.
When the out-of-band QoS signaling is used the Media Gateway When the out-of-band QoS signaling is used the Media Gateway
Controller (MGC) will be acting as the NSIS Initiator. Controller (MGC) will be acting as the NSIS Initiator.
In the second scenario the voice provider manages a set of traffic In the second scenario the voice provider manages a set of traffic
skipping to change at page 35, line 55 skipping to change at page 34, line 10
may use a NSIS Forwarder to do per-flow admission control. In this may use a NSIS Forwarder to do per-flow admission control. In this
case the NSIS signaling is used between the MGC and the NSIS case the NSIS signaling is used between the MGC and the NSIS
Forwarder, which is a separate box here. Hence, the MGC acts only as Forwarder, which is a separate box here. Hence, the MGC acts only as
a NSIS Initiator. This scenario is depicted in figure 2. a NSIS Initiator. This scenario is depicted in figure 2.
+-------------+ ISUP/SIGTRAN +-----+ +-----+ +-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 | | SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+ +-------------+ +-------+-----+---------+ +-----+
: / : \ : / : \
: / +-----+ \ : / +-----+ \
: / | NSIS Forwarder | : / | NF | \
\
: / +-----+ \ : / +-----+ \
: / : \ : / : \
: / +--------:----------+ \ : / +--------:----------+ \
: MEGACO : / : \ : : MEGACO : / : \ :
: : / +-----+ \ : : : / +-----+ \ :
: : / | NMS | \ : : : / | NMS | \ :
: : | +-----+ | : : : | +-----+ | :
: : | | : : : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+ +--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |-- | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/