draft-ietf-nsis-req-09.txt   rfc3726.txt 
Network Working Group M. Brunner (Editor) Network Working Group M. Brunner, Ed.
Internet Draft NEC Request for Comments: 3726 NEC
Category: Informational August 2003 Category: Informational April 2004
Requirements for Signaling Protocols Requirements for Signaling Protocols
<draft-ietf-nsis-req-09.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines requirements for signaling across different This document defines requirements for signaling across different
network environments, such as across administrative and/or network environments, such as across administrative and/or technology
technology domains. Signaling is mainly considered for Quality of domains. Signaling is mainly considered for Quality of Service (Qos)
Service such as The Resource Reservation Protocol, however in recent such as the Resource Reservation Protocol (RSVP). However, in recent
years several other applications of signaling have been defined such years, several other applications of signaling have been defined.
as signaling for label distribution in Multiprotocol Label Switching For example, signaling for label distribution in Multiprotocol Label
or signaling to middleboxes. To achieve wide applicability of the Switching (MPLS) or signaling to middleboxes. To achieve wide
requirements, the starting point is a diverse set of scenarios/use applicability of the requirements, the starting point is a diverse
cases concerning various types of networks and application set of scenarios/use cases concerning various types of networks and
interactions. This document presents the assumptions before listing application interactions. This document presents the assumptions
the requirements. The requirements are grouped according to areas before listing the requirements. The requirements are grouped
such as architecture and design goals, signaling flows, layering, according to areas such as architecture and design goals, signaling
performance, flexibility, security, and mobility. flows, layering, performance, flexibility, security, and mobility.
Table of Contents Table of Contents
Status of this Memo................................................1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
Abstract...........................................................1 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 5
Table of Contents..................................................2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Introduction.....................................................4 3. Problem Statement and Scope. . . . . . . . . . . . . . . . . . 6
1.1. Keywords....................................................4 4. Assumptions and Exclusions . . . . . . . . . . . . . . . . . . 8
2 Terminology......................................................4 4.1. Assumptions and Non-Assumptions. . . . . . . . . . . . . 8
3 Problem Statement and Scope......................................5 4.2. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 9
4 Assumptions and Exclusions.......................................6 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Assumptions and Non-Assumptions................................6 5.1. Architecture and Design Goals. . . . . . . . . . . . . . 11
4.2 Exclusions.....................................................7 5.1.1. NSIS SHOULD Provide Availability Information
5 Requirements.....................................................9 on Request . . . . . . . . . . . . . . . . . . . 11
5.1 Architecture and Design Goals..................................9 5.1.2. NSIS MUST be Designed Modularly. . . . . . . . . 11
5.1.1 NSIS SHOULD provide availability information on request......9 5.1.3. NSIS MUST Decouple Protocol and Information. . . 12
5.1.2 NSIS MUST be designed modularly..............................9 5.1.4. NSIS MUST Support Independence of Signaling and
5.1.3 NSIS MUST decouple protocol and information.................10 Network Control Paradigm . . . . . . . . . . . . 12
5.1.4 NSIS MUST support independence of signaling and network 5.1.5. NSIS SHOULD be Able to Carry Opaque Objects. . . 12
control paradigm..................................................10 5.2. Signaling Flows. . . . . . . . . . . . . . . . . . . . . 12
5.1.5 NSIS SHOULD be able to carry opaque objects.................10 5.2.1. The Placement of NSIS Initiator, Forwarder, and
5.2 Signaling Flows...............................................10 Responder Anywhere in the Network MUST be
5.2.1 The placement of NSIS Initiator, Forwarder, and Responder Allowed. . . . . . . . . . . . . . . . . . . . . 12
anywhere in the network MUST be allowed...........................10 5.2.2. NSIS MUST Support Path-Coupled and MAY Support
5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled Path-Decoupled Signaling . . . . . . . . . . . . 13
signaling.........................................................11 5.2.3. Concealment of Topology and Technology
5.2.3 Concealment of topology and technology information SHOULD be Information SHOULD be Possible . . . . . . . . . 13
possible..........................................................11 5.2.4. Transparent Signaling Through Networks SHOULD be
5.2.4 Transparent signaling through networks SHOULD be possible...11 Possible . . . . . . . . . . . . . . . . . . . . 13
5.3 Messaging.....................................................11 5.3. Messaging. . . . . . . . . . . . . . . . . . . . . . . . 13
5.3.1 Explicit erasure of state MUST be possible..................11 5.3.1. Explicit Erasure of State MUST be Possible . . . 13
5.3.2 Automatic release of state after failure MUST be possible...11 5.3.2. Automatic Release of State After Failure MUST be
5.3.3 NSIS SHOULD allow for sending notifications upstream........12 Possible . . . . . . . . . . . . . . . . . . . . 14
5.3.4 Establishment and refusal to set up state MUST be notified..13 5.3.3. NSIS SHOULD Allow for Sending Notifications
5.3.5 NSIS MUST allow for local information exchange..............13 Upstream . . . . . . . . . . . . . . . . . . . . 14
5.4 Control Information...........................................13 5.3.4. Establishment and Refusal to set up State MUST
5.4.1 Mutability information on parameters SHOULD be possible.....13 be Notified. . . . . . . . . . . . . . . . . . . 15
5.4.2 It SHOULD be possible to add and remove local domain 5.3.5. NSIS MUST Allow for Local Information Exchange . 15
information.......................................................13 5.4. Control Information. . . . . . . . . . . . . . . . . . . 16
5.4.3 State MUST be addressed independent of flow identification..14 5.4.1. Mutability Information on Parameters SHOULD be
5.4.4 Modification of already established state SHOULD be seamless14 Possible . . . . . . . . . . . . . . . . . . . . 16
5.4.5 Grouping of signaling for several micro-flows MAY be provided 5.4.2. It SHOULD be Possible to Add and Remove Local
..................................................................14 Domain Information . . . . . . . . . . . . . . . 16
5.5 Performance...................................................14 5.4.3. State MUST be Addressed Independent of Flow
5.5.1 Scalability.................................................15 Identification . . . . . . . . . . . . . . . . . 16
5.5.2 NSIS SHOULD allow for low latency in setup..................15 5.4.4. Modification of Already Established State SHOULD
5.5.3 NSIS MUST allow for low bandwidth consumption for the be Seamless. . . . . . . . . . . . . . . . . . . 16
signaling protocol................................................15 5.4.5. Grouping of Signaling for Several Micro-Flows
5.5.4 NSIS SHOULD allow to constrain load on devices..............16 MAY be Provided. . . . . . . . . . . . . . . . . 17
5.5.5 NSIS SHOULD target the highest possible network utilization.16 5.5. Performance. . . . . . . . . . . . . . . . . . . . . . . 17
5.6 Flexibility...................................................16 5.5.1. Scalability. . . . . . . . . . . . . . . . . . . 17
5.6.1 Flow aggregation............................................16 5.5.2. NSIS SHOULD Allow for Low Latency in Setup . . . 18
5.6.2 Flexibility in the placement of the NSIS Initiator/Responder16 5.5.3. NSIS MUST Allow for Low Bandwidth Consumption
5.6.3 Flexibility in the initiation of state change...............16 for the Signaling Protocol . . . . . . . . . . . 18
5.6.4 SHOULD support network-initiated state change...............17 5.5.4. NSIS SHOULD Allow to Constrain Load on Devices . 18
5.6.5 Uni / bi-directional state setup............................17 5.5.5. NSIS SHOULD Target the Highest Possible Network
5.7 Security......................................................17 Utilization. . . . . . . . . . . . . . . . . . . 18
5.7.1 Authentication of signaling requests........................17 5.6. Flexibility. . . . . . . . . . . . . . . . . . . . . . . 19
5.7.2 Request Authorization.......................................17 5.6.1. Flow Aggregation . . . . . . . . . . . . . . . . 19
5.7.3 Integrity protection........................................18 5.6.2. Flexibility in the Placement of the NSIS
5.7.4 Replay protection...........................................18 Initiator/Responder. . . . . . . . . . . . . . . 19
5.7.5 Hop-by-hop security.........................................18 5.6.3. Flexibility in the Initiation of State Change. . 19
5.7.6 Identity confidentiality and network topology hiding........18 5.6.4. SHOULD Support Network-Initiated State Change. . 19
5.7.7 Denial-of-service attacks...................................18 5.6.5. Uni / Bi-directional State Setup . . . . . . . . 20
5.7.8 Confidentiality of signaling messages.......................19 5.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7.9 Ownership of state..........................................19 5.7.1. Authentication of Signaling Requests . . . . . . 20
5.8 Mobility......................................................19 5.7.2. Request Authorization. . . . . . . . . . . . . . 20
5.8.1 Allow efficient service re-establishment after handover.....19 5.7.3. Integrity Protection . . . . . . . . . . . . . . 20
5.9 Interworking with other protocols and techniques..............19 5.7.4. Replay Protection. . . . . . . . . . . . . . . . 21
5.9.1 MUST interwork with IP tunneling............................19 5.7.5. Hop-by-Hop Security. . . . . . . . . . . . . . . 21
5.9.2 MUST NOT constrain either to IPv4 or IPv6...................20 5.7.6. Identity Confidentiality and Network Topology
5.9.3 MUST be independent from charging model.....................20 Hiding . . . . . . . . . . . . . . . . . . . . . 21
5.9.4 SHOULD provide hooks for AAA protocols......................20 5.7.7. Denial-of-Service Attacks. . . . . . . . . . . . 21
5.9.5 SHOULD work with seamless handoff protocols.................20 5.7.8. Confidentiality of Signaling Messages. . . . . . 22
5.9.6 MUST work with traditional routing..........................20 5.7.9. Ownership of State . . . . . . . . . . . . . . . 22
5.10 Operational..................................................20 5.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 22
5.10.1 Ability to assign transport quality to signaling messages..20 5.8.1. Allow Efficient Service Re-Establishment After
5.10.2 Graceful fail over.........................................21 Handover . . . . . . . . . . . . . . . . . . . . 22
5.10.3 Graceful handling of NSIS entity problems..................21 5.9. Interworking with Other Protocols and Techniques . . . . 22
6 Security Considerations.........................................21 5.9.1. MUST Interwork with IP Tunneling . . . . . . . . 22
7 References......................................................21 5.9.2. MUST NOT Constrain Either to IPv4 or IPv6. . . . 23
7.1 Normative References..........................................21 5.9.3. MUST be Independent from Charging Model. . . . . 23
7.2 Non-Normative References......................................21 5.9.4. SHOULD Provide Hooks for AAA Protocols . . . . . 23
8 Acknowledgments.................................................21 5.9.5. SHOULD work with Seamless Handoff Protocols. . . 23
9 Author's Addresses..............................................22 5.9.6. MUST Work with Traditional Routing . . . . . . . 23
10 Appendix: Scenarios/Use cases..................................23 5.10. Operational. . . . . . . . . . . . . . . . . . . . . . . 23
10.1 Terminal Mobility............................................23 5.10.1. Ability to Assign Transport Quality to Signaling
10.2 Wireless Networks............................................25 Messages . . . . . . . . . . . . . . . . . . . . 23
10.3 An example scenario for 3G wireless networks.................26 5.10.2. Graceful Fail Over . . . . . . . . . . . . . . . 24
10.4 Wired part of wireless network...............................27 5.10.3. Graceful Handling of NSIS Entity Problems. . . . 24
10.5 Session Mobility.............................................29 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
10.6 QoS reservation/negotiation from access to core network......29 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 24
10.7 QoS reservation/negotiation over administrative boundaries...30 8. Appendix: Scenarios/Use Cases. . . . . . . . . . . . . . . . . 26
10.8 QoS signaling between PSTN gateways and backbone routers.....30 8.1. Terminal Mobility. . . . . . . . . . . . . . . . . . . . 26
10.9 PSTN trunking gateway........................................32 8.2. Wireless Networks. . . . . . . . . . . . . . . . . . . . 28
10.10 An application requests end-to-end QoS path from the network34 8.3. An Example Scenario for 3G Wireless Networks . . . . . . 29
10.11 QOS for Virtual Private Networks............................34 8.4. Wired Part of Wireless Network . . . . . . . . . . . . . 31
10.11.1 Tunnel end points at the Customer premises................34 8.5. Session Mobility . . . . . . . . . . . . . . . . . . . . 33
10.11.2 Tunnel end points at the provider premises................35 8.6. QoS Reservation/Negotiation from Access to Core Network. 34
8.7. QoS Reservation/Negotiation Over Administrative
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 34
8.8. QoS Signaling Between PSTN Gateways and Backbone Routers 35
8.9. PSTN Trunking Gateway. . . . . . . . . . . . . . . . . . 36
8.10. An Application Requests End-to-End QoS Path from the
Network. . . . . . . . . . . . . . . . . . . . . . . . . 38
8.11. QOS for Virtual Private Networks . . . . . . . . . . . . 39
8.11.1. Tunnel End Points at the Customer Premises . . . 39
8.11.2. Tunnel End Points at the Provider Premises . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.1. Normative References . . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 40
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42
1 Introduction 1. Introduction
This document defines requirements for signaling across different This document is the product of the Next Steps in Signaling (NSIS)
network environments. It does not list any problems of existing Working Group. It defines requirements for signaling across
signaling protocols such as [RSVP]. different network environments. It does not list any problems of
existing 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 an idea of the scope within which they are applicable. first have an idea of the scope within which they are applicable.
Therefore, we list use cases and scenarios where an NSIS protocol Therefore, we list use cases and scenarios where an NSIS protocol
could be applied. The scenarios are used to help derive requirements could be applied. The scenarios are used to help derive requirements
and to test the requirements against use cases. and to test the requirements against use cases.
The requirements listed are independent of any application. However, The requirements listed are independent of any application. However,
resource reservation and QoS related issues are used as example resource reservation and QoS related issues are used as examples
within the text. However, QoS is not the only field where signaling within the text. However, QoS is not the only field where signaling
is used in the Internet. Signaling might also be used as a is used in the Internet. Signaling might also be used as a
communication protocol to setup and maintain the state in communication protocol to setup and maintain the state in middleboxes
middleboxes [RFC3234]. [RFC3234].
This document does not cover requirements in relation to some This document does not cover requirements in relation to some
networking areas, in particular, interaction with host and site networking areas, in particular, interaction with host and site
multihoming. We leave these for future analysis. multihoming. We leave these for future analysis.
1.1. Keywords 1.1. Keywords
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
this document are to be interpreted as described in RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[KEYWORDS]. [KEYWORDS].
2 Terminology 2. Terminology
We list the most often used terms in the document. However, they We list the most often used terms in the document. However, they
cannot be made precise without a more complete architectural model, cannot be made precise without a more complete architectural model,
and they are not meant to prescribe any solution in the document. and they are not meant to prescribe any solution in the document.
Where applicable, they will be defined in protocol documents. Where applicable, they will be defined in protocol documents.
NSIS Entity (NE): The function within a node, which implements an NSIS Entity (NE): The function within a node, which implements an
NSIS protocol. In the case of path-coupled signaling, the NE will NSIS protocol. In the case of path-coupled signaling, the NE will
always be on the data path. always be on the data path.
NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may
interact with local state management functions in the network. It interact with local state management functions in the network. It
also propagates NSIS signaling further through the network. also propagates NSIS signaling further through the network.
NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set up
up or manipulate network state. or manipulate network state.
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.
Flow: A traffic stream (sequence of IP packets between two end Flow: A traffic stream (sequence of IP packets between two end
systems) for which a specific packet level treatment is provided. systems) for which a specific packet level treatment is provided.
The flow can be unicast (uni- or bi-directional) or multicast. For The flow can be unicast (uni- or bi-directional) or multicast. For
multicast, a flow can diverge into multiple flows as it propagates multicast, a flow can diverge into multiple flows as it propagates
toward the receiver. For multi-sender multicast, a flow can also toward the receiver. For multi-sender multicast, a flow can also
diverge when viewed in the reverse direction (toward the senders). diverge when viewed in the reverse direction (toward the senders).
Data Path: The route across the networks taken by a flow or Data Path: The route across the networks taken by a flow or
aggregate, i.e. which domains/subdomains it passes through and the aggregate, i.e., which domains/subdomains it passes through and the
egress/ingress points for each. egress/ingress points for each.
Signaling Path: The route across the networks taken by a signaling Signaling Path: The route across the networks taken by a signaling
flow or aggregate, i.e. which domains/subdomains it passes through flow or aggregate, i.e., which domains/subdomains it passes through
and the egress/ingress points for each. and the egress/ingress points for each.
Path-coupled signaling: A mode of signaling where the signaling Path-coupled signaling: A mode of signaling where the signaling
messages follow a path that is tied to the data packets. Signaling messages follow a path that is tied to the data packets. Signaling
messages are routed only through nodes (NEs) that are in the data messages are routed only through nodes (NEs) that are in the data
path. path.
Path-decoupled signaling: Signaling with independent data and Path-decoupled signaling: Signaling with independent data and
signaling paths. Signaling messages are routed to nodes (NEs) which signaling paths. Signaling messages are routed to nodes (NEs) which
are not assumed to be on the data path, but which are (presumably) are not assumed to be on the data path, but which are (presumably)
aware of it. Signaling messages will always be directly addressed to aware of it. Signaling messages will always be directly addressed to
the neighbor NE, and the NI/NR may have no relation at all with the the neighbor NE, and the NI/NR may have no relation at all with the
ultimate data sender or receiver. ultimate data sender or receiver.
Service: A generic something provided by one entity and consumed by Service: A generic something provided by one entity and consumed by
another. It can be constructed by allocating resources. The network another. It can be constructed by allocating resources. The network
can provide it to users or a network node can provide it to packets. can provide it to users or a network node can provide it to packets.
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 sections. requirement sections.
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.) 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, NSIS Forwarder(s), and NSIS Responder including a
including a protocol to carry the information, and the protocol to carry the information, and the syntax/semantics of the
syntax/semantics of the information that is exchanged. Further information that is exchanged. Further statements on
statements on assumptions/exclusions are given in the next Section. assumptions/exclusions are given in the next Section.
The main elements are: The main elements are:
1. Something that starts the request for state to be set up in the 1. Something that starts the request for state to be set up in the
network, the NSIS Initiator. network, the NSIS Initiator.
This might be in the end system or within some other part of the This might be in the end system or within some other part of the
network. The distinguishing feature of the NSIS Initiator is that it network. The distinguishing feature of the NSIS Initiator is that
acts on triggers coming (directly or indirectly) from the higher it acts on triggers coming (directly or indirectly) from the
layers in the end systems. It needs to map the services requested by higher layers in the end systems. It needs to map the services
them, and also provides feedback information to the higher layers, requested by them, and also provides feedback information to the
which might be used by transport layer algorithms or adaptive higher layers, which might be used by transport layer algorithms
applications. or adaptive applications.
2. Something that assists in managing state further along the 2. Something that assists in managing state further along the
signaling path, the NSIS Forwarder. signaling path, the NSIS Forwarder.
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, NSIS Responder, and possibly one interacts with the NSIS Initiator, NSIS Responder, and possibly
or more NSIS Forwarders on the signaling path, edge-to-edge or end- one or more NSIS Forwarders on the signaling path, edge-to-edge or
to-end. end-to-end.
3. Something that terminates the signaling path, the NSIS Responder. 3. Something that terminates the signaling path, the NSIS Responder.
The NSIS responder might be in an end-system or within other The NSIS responder might be in an end-system or within other
equipment. The distinguishing feature of the NSIS Responder is that equipment. The distinguishing feature of the NSIS Responder is
it responds to requests at the end of a signaling path. that it responds to requests at the end of a signaling path.
4. The signaling path traverses an underlying network covering one 4. The signaling path traverses an underlying network covering one or
or more IP hops. The underlying network might use locally different more IP hops. The underlying network might use locally different
technology. For instance, QoS technology has to be provisioned technology. For instance, QoS technology has to be provisioned
appropriately for the service requested. In the QoS example, an NSIS appropriately for the service requested. In the QoS example, an
Forwarder maps service-specific information to technology-related NSIS Forwarder maps service-specific information to technology-
QoS parameters and receives indications about success or failure in related QoS parameters and receives indications about success or
response. failure in response.
5. We can see the network at the level of domains/subdomains rather 5. We can see the network at the level of domains/subdomains rather
than individual routers (except in the special case that the domain than individual routers (except in the special case that the
contains one link). Domains are assumed to be administrative domain contains one link). Domains are assumed to be
entities. So security requirements might apply differently for the administrative entities. So security requirements might apply
signaling between the domains and within a domain. Both cases we differently for the signaling between the domains and within a
deal with in this document. domain. Both cases we deal with in this document.
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 NSIS initiator, and how far towards the point in the network acts as NSIS initiator, and how far towards
other end of the network the signaling propagates. In general, we the other end of the network the signaling propagates. In
could expect NSIS Forwarders to become more 'dense' towards the general, we could expect NSIS Forwarders to become more 'dense'
edges of the network, but this is not a requirement. For example, in towards the edges of the network, but this is not a requirement.
the case of QoS, an over-provisioned domain might contain no NSIS For example, in the case of QoS, an over-provisioned domain might
Forwarders at all (and be NSIS transparent); at the other extreme, contain no NSIS Forwarders at all (and be NSIS transparent); at
NSIS Forwarders might be placed at every router. In the latter case, the other extreme, NSIS Forwarders might be placed at every
QoS provisioning can be carried out in a local implementation- router. In the latter case, QoS provisioning can be carried out
dependent way without further signaling, whereas in the case of in a local implementation-dependent way without further signaling,
remote NSIS Forwarders, a protocol might be needed to control the whereas in the case of remote NSIS Forwarders, a protocol might be
routers along the path. This protocol is then independent of the needed to control the routers along the path. This protocol is
end-to-end NSIS signaling. then independent of the end-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 a higher- interpreted anywhere within the network. Such signaling is a
layer issue and IETF protocols such as SIP etc. can be used. higher-layer issue and IETF protocols such as SIP etc. can be
used.
3. Where the signaling does cover several domains, we do not exclude 3. Where the signaling does cover several domains, we do not exclude
that different signaling protocols are used in each domain. We only that different signaling protocols are used in each domain. We
place requirements on the universality of the control information only place requirements on the universality of the control
that is being transported. (The goals here would be to allow the use information that is being transported. (The goals here would be
of signaling protocols, which are matched to the characteristics of to allow the use of signaling protocols, which are matched to the
the portion of the network being traversed.) Note that the outcome characteristics of the portion of the network being traversed.)
of NSIS work might result in various flavors of the same protocol. Note that the outcome of NSIS work might result in various flavors
of the same protocol.
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. For for are known in advance of the signaling protocol running. For
instance in the QoS example, the service definition includes QoS instance in the QoS example, the service definition includes QoS
parameters, lifetime of QoS guarantee etc., or any other service- parameters, lifetime of QoS guarantee etc., or any other service-
specific parameters. specific parameters.
There are many ways service requesters get to know about available There are many ways service requesters get to know about available
services. There might be standardized services, the definition can services. There might be standardized services, the definition
be negotiated together with a contract, the service definition is can be negotiated together with a contract, the service definition
published in some on-line directory (e.g., at a Web page), and so is published in some on-line directory (e.g., at a Web page), and
on. so on.
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
right nodes along the data path, etc.) The discovery of the NSIS the right nodes along the data path, etc.). The discovery of the
entities has security implications that need to be addressed NSIS entities has security implications that need to be addressed
properly. For some security mechanisms (i.e. Kerberos, pre-shared properly. For some security mechanisms (i.e., Kerberos, pre-
secret) it is required to know the identity of the other entity. shared secret) it is required to know the identity of the other
Hence the discovery mechanism may provide means to learn this entity. Hence the discovery mechanism may provide means to learn
identity, which is then later used to retrieve the required keys and this identity, which is then later used to retrieve the required
parameters. keys and parameters.
6. NSIS assumes layer 3 routing and the determination of next data 6. NSIS assumes layer 3 routing and the determination of next data
node selection is not done by NSIS. node selection is not done by NSIS.
4.2 Exclusions 4.2. Exclusions
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
and information semantics that would be needed of the signaling capabilities and information semantics that would be needed of
protocol. the signaling protocol.
3. Specific mechanisms and protocols for provisioning or other 3. Specific mechanisms and protocols for provisioning or other
network control functions within a domain/subdomain are not network control functions within a domain/subdomain are not
considered. The goal is to reuse existing functions and protocols considered. The goal is to reuse existing functions and
unchanged. However, NSIS itself can be used for signaling within a protocols unchanged. However, NSIS itself can be used for
domain/subdomain. signaling within a domain/subdomain.
For instance in the QoS example, it means that the setting of QoS For instance in the QoS example, it means that the setting of QoS
mechanisms in a domain is out of scope, but if we have a tunnel, mechanisms in a domain is out of scope, but if we have a tunnel,
NSIS could also be used for tunnel setup with QoS guarantees. It NSIS could also be used for tunnel setup with QoS guarantees. It
should be possible to exploit these mechanisms optimally within the should be possible to exploit these mechanisms optimally within
end-to-end context. Consideration of how to do this might generate the end-to-end context. Consideration of how to do this might
new requirements for NSIS however. For example, the information generate new requirements for NSIS however. For example, the
needed by a NSIS Forwarder to manage a radio subnetwork needs to be information needed by a NSIS Forwarder to manage a radio
provided by the NSIS solution. 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 provisioning mechanisms are not network layer and underlying provisioning mechanisms are not
considered. considered.
5. Interaction with resource management or other internal state 5. Interaction with resource management or other internal state
management capabilities is not considered. Standard protocols might management capabilities is not considered. Standard protocols
be used for this. This may imply requirements for the sort of might be used for this. This may imply requirements for the sort
information that should be exchanged between the NSIS entities. of information that should 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.
7. Service definitions and in particular QoS services and classes 7. Service definitions and in particular QoS services and classes
are out of scope. Together with the service definition any are out of scope. Together with the service definition any
definition of service specific parameters are not considered in this definition of service specific parameters are not considered in
document. Only the base NSIS signaling protocol for transporting the this document. Only the base NSIS signaling protocol for
service information are addressed. transporting the service information are addressed.
8. Similarly, specific methods, protocols, and ways to express 8. Similarly, specific methods, protocols, and ways to express
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.).
9. The specification of any extensions needed to signal information 9. 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 to
information are considered outside of the scope of NSIS working NSIS information are considered outside of the scope of NSIS
group, as this work is in the direct scope of other IETF working working group, as this work is in the direct scope of other IETF
groups (e.g. MMUSIC). working groups (e.g., MMUSIC).
10. Handoff decision and trigger sources: An NSIS protocol is not 10. 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 situations 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 the particular service again. The basic underlying signaling for the particular service again. The basic underlying
assumption is that the route comes first (defining the path) and the assumption is that the route comes first (defining the path) and
signaling comes after it (following the path). This doesn't prevent the signaling comes after it (following the path). This doesn't
a signaling application at some node interacting with something that prevent a signaling application at some node interacting with
modifies the path, but the requirement is then just for NSIS to live something that modifies the path, but the requirement is then
with that possibility. However, NSIS must interwork with several just for NSIS to live with that possibility. However, NSIS must
protocols for mobility management. interwork with several protocols for mobility management.
11. Service monitoring is out of scope. It is heavily dependent on 11. Service monitoring is out of scope. It is heavily dependent on
the 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, respecting the framework, scoping assumptions, and solution, respecting the problem statement, scoping assumptions, and
terminology considered earlier. The requirements are in subsections, terminology considered earlier. The requirements are in subsections,
grouped roughly according to general technical aspects: architecture grouped roughly according to general technical aspects: architecture
and design goals, topology issues, parameters, performance, and design goals, topology issues, parameters, performance, security,
security, information, and flexibility. 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 be lightweight in implementation complexity and
resource consumption requirements in NSIS Entities. We use the terms resource consumption requirements in NSIS Entities. We use the terms
'access' and 'core' informally in the discussion of some particular 'access' and 'core' informally in the discussion of some particular
requirements to refer to deployment conditions where particular requirements to refer to deployment conditions where particular
protocol attributes, especially performance characteristics, have protocol attributes, especially performance characteristics, have
special importance. Specifically, 'access' refers to lower capacity special importance. Specifically, 'access' refers to lower capacity
networks and fewer users and sessions. 'Core' refers to high networks with fewer users and sessions. 'Core' refers to high
capacity networks with a large number of users and sessions. capacity networks with a large number of users and sessions.
One approach to this is that the solution could deal with certain One approach to this is that the solution could deal with certain
requirements via modular components or capabilities, which are requirements via modular components or capabilities, which are
optional to implement or use in individual nodes. optional to implement or use in individual nodes.
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 NSIS SHOULD provide availability information on request 5.1.1. NSIS SHOULD Provide Availability Information on Request
NSIS SHOULD provide a mechanism to check whether state to be setup NSIS SHOULD provide a mechanism to check whether state to be setup is
is available without setting it up. For the resource reservation available without setting it up. For the resource reservation
example this translates into checking resource availability without example this translates into checking resource availability without
performing resource reservation. In some scenarios, e.g., the mobile performing resource reservation. In some scenarios, e.g., the mobile
terminal scenario, it is required to query, whether resources are terminal scenario, it is required to query, whether resources are
available, without performing a reservation on the resource. available, without performing a reservation on the resource.
5.1.2 NSIS MUST be designed modularly 5.1.2. NSIS MUST be Designed Modularly
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,
prone versus reliable, ...). This implies low bandwidth signaling, error-prone versus reliable, ...). This implies low bandwidth
and elimination of redundant information MUST be supported if signaling, and elimination of redundant information MUST be
necessary. supported if necessary.
- State setup for uni- and bi-directional flows is possible - State setup for uni- and bi-directional flows is possible.
- Extensible in the future with different add-ons for certain - Extensible in the future with different add-ons for certain
environments or scenarios environments or scenarios.
- Protocol layering, where appropriate. This means NSIS MUST provide - Protocol layering, where appropriate. This means NSIS MUST
a base protocol, which can be adapted to different environments. provide a base protocol, which can be adapted to different
environments.
5.1.3 NSIS MUST decouple protocol and information 5.1.3. NSIS MUST Decouple Protocol and Information
The signaling protocol MUST be clearly separated from the control The signaling protocol MUST be clearly separated from the control
information being transported. This provides for the independent information being transported. This provides for the independent
development of these two aspects of the solution, and allows for development of these two aspects of the solution, and allows for this
this control information to be carried within other protocols, control information to be carried within other protocols, including
including application layer ones, existing ones or those being application layer ones, existing ones or those being developed in the
developed in the future. The flexibility gained in the transport of future. The flexibility gained in the transport of information
information allows for the applicability of the same protocol in allows for the applicability of the same protocol in various
various scenarios. scenarios.
However, note that the information carried needs to be standardized; However, note that the information carried needs to be standardized;
otherwise interoperability is difficult to achieve. otherwise interoperability is difficult to achieve.
5.1.4 NSIS MUST support independence of signaling and network control 5.1.4. NSIS MUST Support Independence of Signaling and Network Control
paradigm Paradigm
The signaling MUST be independent of the paradigm and mechanism of The signaling MUST be independent of the paradigm and mechanism of
network control. E.g., in the case of signaling for QoS, the network control. 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.5 NSIS SHOULD be able to carry opaque objects 5.1.5. NSIS SHOULD be Able to Carry Opaque Objects
NSIS SHOULD be able to pass around opaque objects, which are NSIS SHOULD be able to pass around opaque objects, which are
interpreted only by some NSIS-capable nodes. interpreted only by some NSIS-capable nodes.
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
path, between what entities (end-systems, routers, middle boxes, path, between what entities (end-systems, routers, middle boxes,
management systems), in which direction. management systems), in which direction.
5.2.1 The placement of NSIS Initiator, Forwarder, and Responder 5.2.1. The placement of NSIS Initiator, Forwarder, and Responder
anywhere in the network MUST be allowed Anywhere in the Network MUST be Allowed
The protocol MUST work in various scenarios such as host-to-network- The protocol MUST work in various scenarios such as host-to-network-
to-host, edge-to-edge, (e.g., just within one provider's domain), to-host, edge-to-edge, (e.g., just within one provider's domain),
user-to-network (from end system into the network, ending, e.g., at user-to-network (from end system into the network, ending, e.g., at
the entry to the network and vice versa), and network-to-network the entry to the network and vice versa), and network-to-network
(e.g., between providers). (e.g., between providers).
Placing the NSIS Forwarder and NSIS Initiator functions at different Placing the NSIS Forwarder and NSIS Initiator functions at different
locations allows for various scenarios to work with the same locations allows for various scenarios to work with the same
protocol. protocol.
5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled 5.2.2. NSIS MUST Support Path-Coupled and MAY Support Path-Decoupled
signaling. Signaling.
The path-coupled signaling mode MUST be supported. NSIS signaling The path-coupled signaling mode MUST be supported. NSIS signaling
messages are routed only through nodes (NEs) that are in the data messages are routed only through nodes (NEs) that are in the data
path. path.
However, there is a set of scenarios, where signaling is not on the However, there is a set of scenarios, where signaling is not on the
data path. Therefore, NSIS MAY support the path-decoupled signaling data path. Therefore, NSIS MAY support the path-decoupled signaling
mode, where signaling messages are routed to nodes (NEs), which are mode, where signaling messages are routed to nodes (NEs), which are
not assumed to be on the data path, but which are aware of it. not assumed to be on the data path, but which are aware of it.
5.2.3 Concealment of topology and technology information SHOULD be 5.2.3. Concealment of Topology and Technology Information SHOULD be
possible Possible
The NSIS protocol SHOULD allow for hiding the internal structure of The NSIS protocol SHOULD allow for hiding the internal structure of a
a NSIS domain from end-nodes and from other networks. Hence an 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 Transparent signaling through networks SHOULD be possible 5.2.4. Transparent Signaling Through Networks SHOULD be Possible
It SHOULD be possible that the signaling for some flows traverses It SHOULD be possible that the signaling for some flows traverses
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 signaling for aggregates established at the domain edge, with the signaling for
individual flows passing transparently through it. individual flows 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
big pipes/trunks are setup using NSIS signaling, but also flows pipes/trunks are setup using NSIS signaling, but also flows which run
which run within that big pipe/trunk are setup using NSIS. within that big pipe/trunk are setup using NSIS.
5.3 Messaging 5.3. Messaging
5.3.1 Explicit erasure of state MUST be possible 5.3.1. Explicit Erasure of State MUST be Possible
When state along a path is no longer necessary, e.g., because the When state along a path 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 erase the state explicitly. off, it MUST be possible to erase the state explicitly.
5.3.2 Automatic release of state after failure MUST be possible 5.3.2. Automatic Release of State After Failure MUST be Possible
When the NSIS Initiator goes down, the state it requested in the When the NSIS Initiator goes down, the state it requested in the
network SHOULD be released, since it will most likely no longer be network SHOULD be released, since it will most likely no longer be
necessary. necessary.
After detection of a failure in the network, any NSIS After detection of a failure in the network, any NSIS
Forwarder/Initiator MUST be able to release state it is involved in. Forwarder/Initiator MUST be able to release state it is involved in.
For example, this may require signaling of the "Release after For example, this may require signaling of the "Release after
Failure" message upstream as well as downstream, or soft state Failure" message upstream as well as downstream, or soft state timing
timing out. out.
The goal is to prevent stale state within the network and adds The goal is to prevent stale state within the network and add
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. Note as well, that transient failures in NSIS processing mechanism. Note as well, that transient failures in NSIS processing
shouldn't necessarily have to cause all state to be released shouldn't necessarily have to cause all state to be released
immediately. immediately.
5.3.3 NSIS SHOULD allow for sending notifications upstream 5.3.3. NSIS SHOULD Allow for Sending Notifications Upstream
NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS
Forwarder upstream, if there is a state change inside the network. Forwarder upstream, if there is a state change inside the network.
There are various types of network changes for instance among them: There are various types of network changes for instance 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 degradation (or actual short term degradation) of the provided
service was overcome by the network (NSIS Forwarder) itself. service was overcome by the network (NSIS Forwarder) itself.
skipping to change at page 12, line 56 skipping to change at page 15, line 13
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
location of the state change. location of the state change.
The notifications may or may not be in response to a NSIS message. The notifications may or may not be in response to a NSIS message.
This means an NSIS entity has to be able to handle notifications at This means an NSIS entity has to be able to handle notifications at
any time. any time.
Note however, that there are a number of security consideration Note however, that there are a number of security consideration needs
needs to be solved with notification, even more important if the to be solved with notification, even more important if the
notification is sent without prior request (asynchronously). The notification is sent without prior request (asynchronously). The
problem basically is, that everybody could send notifications to any problem basically is, that everybody could send notifications to any
NSIS entity and the NSIS entity most likely reacts on the NSIS entity and the NSIS entity most likely reacts on the
notification. For example, if it gets an error notification it might notification. For example, if it gets an error notification it might
erase state, even if everything is ok. So the notification might erase state, even if everything is ok. So the notification might
depend on security associations between the sender of the depend on security associations between the sender of the
notification and its receiver. If a hop-by-hop security mechanism is notification and its receiver. If a hop-by-hop security mechanism is
chosen, this implies also that notifications need to be sent on the chosen, this implies also that notifications need to be sent on the
reverse path. reverse path.
5.3.4 Establishment and refusal to set up state MUST be notified. 5.3.4. Establishment and Refusal to Set Up State MUST be Notified
An NR MUST acknowledge establishment of state on behalf of the NI A NR MUST acknowledge establishment of state on behalf of the NI
requesting establishment of that state. A refusal to set up state requesting establishment of that state. A refusal to set up state
MUST be replied with a negative acknowledgement by the NE refusing MUST be replied with a negative acknowledgement by the NE refusing to
to set up state. It MUST be sent to the NI. Depending on the set up state. It MUST be sent to the NI. Depending on the signaling
signaling application the (positive or negative) notifications may application the (positive or negative) notifications may have to pass
have to pass through further NEs upstream. Information on the reason through further NEs upstream. Information on the reason of the
of the refusal to set up state MAY be made available. For example, refusal to set up state MAY be made available. For example, in the
in the resource reservation example, together with a negative resource reservation example, together with a negative answer, the
answer, the amount of resources available might also be returned. amount of resources available might also be returned.
5.3.5 NSIS MUST allow for local information exchange 5.3.5. NSIS MUST Allow for 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. The local information exchange is performed by a number of domain. The local information exchange is performed by a number of
separate messages not belonging to an end-to-end signaling process. separate messages not belonging to an end-to-end signaling process.
Local information might, for example, be IP addresses , notification Local information might, for example, be IP addresses , notification
of successful or erroneous processing of signaling messages, or of successful or erroneous processing of signaling messages, or other
other conditions. conditions.
In some cases, the NSIS signaling protocol MAY carry identification In some cases, the NSIS signaling protocol MAY carry identification
of the NSIS Forwarders located at the boundaries of a domain. of the NSIS Forwarders located at the boundaries of a domain.
However, the identification of edge should not be visible to the end However, the identification of edge should not be visible to the end
host (NSIS Initiator) and only applies within one administrative host (NSIS Initiator) and only applies within one administrative
domain. domain.
5.4 Control Information 5.4. Control Information
This section contains requirements related to the control This section contains requirements related to the control information
information that needs to be exchanged. that needs to be exchanged.
5.4.1 Mutability information on parameters SHOULD be possible 5.4.1. Mutability Information on Parameters SHOULD be Possible
It is possible that nodes modify parameters of a signaling message. It is possible that nodes modify parameters of a signaling message.
However, it SHOULD be possible for the NSIS Initiator to control the However, it SHOULD be possible for the NSIS Initiator to control the
mutability of the signaled information. For example, the NSIS mutability of the signaled information. For example, the NSIS
Initiator should be able to control what is requested end to end, Initiator should be able to control what is requested end-to-end,
without the request being gradually mutated as it passes through a without the request being gradually mutated as it passes through a
sequence of nodes. sequence of nodes.
5.4.2 It SHOULD be possible to add and remove local domain information 5.4.2. It SHOULD be Possible to Add and Remove Local Domain Information
It SHOULD be possible to add and remove local scope elements. It SHOULD be possible to add and remove local scope elements.
Compared to Requirement 5.3.5 this requirement does use the normal Compared to Requirement 5.3.5 this requirement does use the normal
signaling process and message exchange for transporting local signaling process and message exchange for transporting local
information. For example, at the entrance to a domain domain- information. For example, at the entrance to a domain, domain-
specific information is added, which is used in this domain only, specific information is added information is added, which is used in
and the information is removed again when a signaling message leaves this domain only, and the information is removed again when a
the domain. The motivation is in the economy of re-using the signaling message leaves the domain. The motivation is in the
protocol for domain internal signaling of various information economy of re-using the protocol for domain internal signaling of
pieces. Where additional information is needed within a particular various information pieces. Where additional information is needed
domain, it should be possible to carry this at the same time as the within a particular domain, it should be possible to carry this at
end-to-end information. the same time as the end-to-end information.
5.4.3 State MUST be addressed independent of flow identification 5.4.3. State MUST be Addressed Independent of Flow Identification
Addressing or identifying state MUST be independent of the flow Addressing or identifying state MUST be independent of the flow
identifier (flow end-points, topological addresses). Various identifier (flow end-points, topological addresses). Various
scenarios in the mobility area require this independence because scenarios in the mobility area require this independence because
flows resulting from handoff might have changed end-points etc. but flows resulting from handoff might have changed end-points etc. but
still have the same service requirement. Also several proxy-based still have the same service requirement. Also several proxy-based
signaling methods profit from such independence, though these are signaling methods profit from such independence, though these are not
not chartered work items for NSIS. chartered work items for NSIS.
5.4.4 Modification of already established state SHOULD be seamless 5.4.4. Modification of Already Established State SHOULD be Seamless
In many case, the established state needs to be updated (in QoS In many case, the established state needs to be updated (in QoS
example upgrade or downgrade of resource usage). This SHOULD happen example upgrade or downgrade of resource usage). This SHOULD happen
seamlessly without service interruption. At least the signaling seamlessly without service interruption. At least the signaling
protocol should allow for it, even if some data path elements might protocol should allow for it, even if some data path elements might
not be capable of doing so. not be capable of doing so.
5.4.5 Grouping of signaling for several micro-flows MAY be provided 5.4.5. Grouping of Signaling for Several Micro-Flows MAY be Provided
NSIS MAY group signaling information for several micro-flow into one NSIS MAY group signaling information for several micro-flows into one
signaling message. The goal of this is the optimization in terms of signaling message. The goal of this is the optimization in terms of
setup delay, which can happen in parallel. This helps applications setup delay, which can happen in parallel. This helps applications
requesting several flows at once. Also potential refreshes (in case requesting several flows at once. Also potential refreshes (in case
of a soft state solution) might profit from grouping. of a soft state solution) might profit from grouping.
However, the network needs not know that a relationship between the However, the network need not know that a relationship between the
grouped flows exists. There MUST NOT be any transactional semantic grouped flows exists. There MUST NOT be any transactional semantic
associated with the grouping. It is only meant for optimization associated with the grouping. It is only meant for optimization
purposes. purposes.
5.5 Performance 5.5. Performance
This section discusses performance requirements and evaluation This section discusses performance requirements and evaluation
criteria and the way in which these could and should be traded off criteria and the way in which these could and should be traded off
against each other in various parts of the solution. against each other in various parts of the solution.
Scalability is always an important requirement for signaling Scalability is always an important requirement for signaling
protocols. However, the type of scalability and its importance protocols. However, the type of scalability and its importance
varies from one scenario to another. varies from one scenario to another.
Note that many of the performance issues are heavily dependent on Note that many of the performance issues are heavily dependent on the
the scenario assumed and are normally a trade-off between speed, scenario assumed and are normally a trade-off between speed,
reliability, complexity, and scalability. The trade-off varies in reliability, complexity, and scalability. The trade-off varies in
different parts of the network. For example, in radio access different parts of the network. For example, in radio access
networks low bandwidth consumption will outweigh the low latency networks low bandwidth consumption will outweigh the low latency
requirement, while in core networks it may be reverse. requirement, while in core networks it may be reverse.
5.5.1 Scalability 5.5.1. Scalability
NSIS MUST be scalable in the number of messages received by a NSIS MUST be scalable in the number of messages received by a
signaling communication partner (NSIS Initiator, NSIS Forwarder, and signaling communication partner (NSIS Initiator, NSIS Forwarder, and
NSIS Responder). The major concern lies in the core of the network, NSIS Responder). The major concern lies in the core of the network,
where large numbers of messages arrive. where large numbers of messages arrive.
It MUST be scalable in number of hand-offs in mobile environments. It MUST be scalable in number of hand-offs in mobile environments.
This mainly applies in access networks, because the core is This mainly applies in access networks, because the core is
transparent to mobility in most cases. transparent to mobility in most cases.
It MUST be scalable in the number of interactions for setting up a It MUST be scalable in the number of interactions for setting up
state. This applies for end-systems setting up several states. Some state. This applies for end-systems setting up several states. Some
servers might be expected to setup a large number of states. servers might be expected to setup a large number of states.
Scalability in the amount of state per entity MUST be achieved for Scalability in the amount of state per entity MUST be achieved for
NSIS Forwarders in the core of the network. NSIS Forwarders in the core of the network.
Scalability in CPU usage MUST be achieved on end terminals and Scalability in CPU usage MUST be achieved on end terminals and
intermediate nodes in case of many state setup processes at the same intermediate nodes in case of many state setup processes at the same
time. time.
Specifically, NSIS MUST work in Internet scale deployments, where Specifically, NSIS MUST work in Internet scale deployments, where the
the use of signaling by hosts becomes universal. Note that use of signaling by hosts becomes universal. Note that requirement
requirement 5.2.4 requires the functionality of transparently 5.2.4 requires the functionality of transparently signaling through
signaling through networks without interpretation. Additionally, networks without interpretation. Additionally, requirement 5.6.1
requirement 5.6.1 lists the capability to aggregate. Furthermore, lists the capability to aggregate. Furthermore, requirement 5.5.4
requirement 5.5.4 states that NSIS should be able to constrain the states that NSIS should be able to constrain the load on devices.
load on devices. Basically, the performance of the signaling MUST Basically, the performance of the signaling MUST degrade gracefully
degrade gracefully rather than catastrophically under overload rather than catastrophically under overload conditions.
conditions.
5.5.2 NSIS SHOULD allow for low latency in setup 5.5.2. NSIS SHOULD Allow for Low Latency in Setup
NSIS SHOULD allow for low latency setup of states. This is only NSIS SHOULD allow for low latency setup of states. This is only
needed in scenarios, where state setups are required on a short time needed in scenarios where state setups are required on a short time
scale (e.g. handover in mobile environments), or where human scale (e.g., handover in mobile environments), or where human
interaction is immediately concerned (e.g., voice communication interaction is immediately concerned (e.g., voice communication setup
setup delay). delay).
5.5.3 NSIS MUST allow for low bandwidth consumption for the signaling 5.5.3. NSIS MUST Allow for Low Bandwidth Consumption for the Signaling
protocol Protocol
NSIS MUST allow for low bandwidth consumption in certain access NSIS MUST allow for low bandwidth consumption in certain access
networks. Again only small sets of scenarios call for low bandwidth, networks. Again only small sets of scenarios call for low bandwidth,
mainly those where wireless links are involved. mainly those where wireless links are involved.
5.5.4 NSIS SHOULD allow to constrain load on devices 5.5.4. NSIS SHOULD Allow to Constrain Load on Devices
The NSIS architecture SHOULD give the ability to constrain the load The NSIS architecture SHOULD give the ability to constrain the load
(CPU load, memory space, signaling bandwidth consumption and (CPU load, memory space, signaling bandwidth consumption and
signaling intensity) on devices where it is needed. One of the signaling intensity) on devices where it is needed. One of the
reasons is that the protocol handling should have a minimal impact reasons is that the protocol handling should have a minimal impact on
on interior (core) nodes. interior (core) nodes.
This can be achieved by many different methods. Examples include This can be achieved by many different methods. Examples include
message aggregation, header compression, minimizing functionality, message aggregation, header compression, minimizing functionality, or
or ignoring signaling in core nodes. The framework may choose any ignoring signaling in core nodes. NSIS may choose any method as long
method as long as the requirement is met. as the requirement is met.
5.5.5 NSIS SHOULD target the highest possible network utilization 5.5.5. NSIS SHOULD Target the Highest Possible Network Utilization
This requirement applies specifically to QoS signaling. This requirement applies specifically to QoS signaling.
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
to its best ability support high resource utilization while its best ability support high resource utilization while maintaining
maintaining appropriate service quality. 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 for signaling many wireless networks), efficient network utilization for signaling
traffic is of critical financial importance. On the other hand traffic is of critical financial importance. On the other hand there
there are other parts of the network where high utilization is not are other parts of the network where high utilization is not
required. 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.
5.6.1 Flow aggregation 5.6.1. Flow Aggregation
NSIS MUST allow for flow aggregation, including the capability to NSIS MUST allow for flow aggregation, including the capability to
select and change the level of aggregation. select and change the level of aggregation.
5.6.2 Flexibility in the placement of the NSIS Initiator/Responder 5.6.2. Flexibility in the Placement of the NSIS Initiator/Responder
NSIS MUST be flexible in placing an NSIS Initiator and NSIS NSIS MUST be flexible in placing an NSIS Initiator and NSIS
Responder. The NSIS Initiator might be located at the sending or the Responder. The NSIS Initiator might be located at the sending or the
receiving side of a data stream, and the NSIS Responder naturally on receiving side of a data stream, and the NSIS Responder naturally on
the other side. the other side.
Also network-initiated signaling and termination MUST be allowed in Also network-initiated signaling and termination MUST be allowed in
various scenarios such as PSTN gateways, some VPNs, and mobility. various scenarios such as PSTN gateways, some VPNs, and mobility.
This means the NSIS Initiator and NSIS Responder might not be at the This means the NSIS Initiator and NSIS Responder might not be at the
end points of the data stream. end points of the data stream.
5.6.3 Flexibility in the initiation of state change 5.6.3. Flexibility in the Initiation of State Change
The NSIS Initiator or the NSIS Responder SHOULD be able to initiate
a change of state. In the example of resource reservation this is The NSIS Initiator or the NSIS Responder SHOULD be able to initiate a
change of state. In the example of resource reservation this is
often referred to as resource re-negotiation. It can happen due to often referred to as resource re-negotiation. It can happen due to
various reasons, such as local resource shortage (CPU, memory on various reasons, such as local resource shortage (CPU, memory on
end-system) or a user changed application preference/profiles. end-system) or a user changed application preference/profiles.
5.6.4 SHOULD support network-initiated state change 5.6.4. SHOULD Support Network-Initiated State Change
NSIS SHOULD support network-initiated state change. In the QoS NSIS SHOULD support network-initiated state change. In the QoS
example, this is used in cases, where the network is not able to example, this is used in cases, where the network is not able to
further guarantee resources and wants to e.g. downgrade a resource further guarantee resources and wants to e.g., downgrade a resource
reservation. reservation.
5.6.5 Uni / bi-directional state setup 5.6.5. Uni / Bi-Directional State Setup
Both unidirectional as well as bi-direction state setup SHOULD be Both unidirectional as well as bi-direction state setup SHOULD be
possible. With bi-directional state setup we mean that the state for possible. With bi-directional state setup we mean that the state for
bi-directional data flows is setup. The bi-directional data flows bi-directional data flows is setup. The bi-directional data flows
have the same end-points, but the path in the two directions does have the same end-points, but the path in the two directions does not
not need to be the same. need to be the same.
The goal of a bi-directional state setup is mainly an optimization The goal of a bi-directional state setup is mainly an optimization in
in terms of setup delay. There is no requirements on constrains such terms of setup delay. There is no requirements on constrains such as
as use of the same data path etc. use of the same data path etc.
5.7 Security 5.7. Security
This section discusses security-related requirements. The NSIS This section discusses security-related requirements. The NSIS
protocol MUST provide means for security, but it MUST be allowed protocol MUST provide means for security, but it MUST be allowed that
that nodes implementing NSIS signaling do not need use the security nodes implementing NSIS signaling do not have to use the security
means. 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.
5.7.2 Request Authorization 5.7.2. Request Authorization
The signaling protocol MUST provide means to authorize state setup The signaling protocol MUST provide means to authorize state setup
requests. This requirement demands a hook to interact with a policy requests. This requirement demands a hook to interact with a policy
entity to request authorization data. This allows an authenticated entity to request authorization data. This allows an authenticated
entity to be associated with authorization data and to verify the entity to be associated with authorization data and to verify the
request. Authorization prevents state setup by unauthorized entities, request. Authorization prevents state setup by unauthorized
setups violating policies, and theft of service. Additionally it entities, setups violating policies, and theft of service.
limits denial of service attacks against parts of the network or the Additionally it limits denial of service attacks against parts of the
entire network caused by unrestricted state setups. Additionally it network or the entire network caused by unrestricted state setups.
might be helpful to provide some means to inform other protocols of Additionally it might be helpful to provide some means to inform
participating nodes within the same administrative domain about a other protocols of participating nodes within the same administrative
previous successful authorization event. domain about a previous successful authorization event.
5.7.3 Integrity protection 5.7.3. Integrity Protection
The signaling protocol MUST provide means to protect the message The signaling protocol MUST provide means to protect the message
payloads against modifications. Integrity protection prevents an payloads against modifications. Integrity protection prevents an
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. network element.
5.7.5 Hop-by-hop security 5.7.5. Hop-by-Hop Security
Channel security between signaling entities MUST be implemented. It is Channel security between signaling entities MUST be implemented. It
a well known and proven concept in Quality-of-Service and other is a well known and proven concept in Quality of Service and other
signaling protocols that allows intermediate nodes that actively signaling protocols to have intermediate nodes that actively
participate in the protocol to modify the messages as it is required participate in the protocol to modify the messages as it is required
by processing rules. Note that this requirement does not exclude end- by processing rules. Note that this requirement does not exclude
to-end or network-to-network security of a signaling message. End-to- end-to-end or network-to-network security of a signaling message.
end security between the NSIS Initiator and the NSIS Responder may be End-to-end security between the NSIS Initiator and the NSIS Responder
used to provide protection of non-mutable data fields. Network-to- may be used to provide protection of non-mutable data fields.
network security refers to the protection of messages over various Network-to-network security refers to the protection of messages over
hops but not in an end-to-end manner i.e. protected over a particular various hops but not in an end-to-end manner i.e., protected over a
network. particular network.
5.7.6 Identity confidentiality and network topology hiding 5.7.6. Identity Confidentiality and Network Topology Hiding
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
enough information for the nodes in the access network to collect provide enough information for the nodes in the access network to
accounting data. collect accounting data.
Network topology hiding MAY be supported to prevent entities along Network topology hiding MAY be supported to prevent entities along
the path to learn the topology of a network. Supporting this property the path to learn the topology of a network. Supporting this
might conflict with a diagnostic capability. property might conflict with a diagnostic capability.
5.7.7 Denial-of-service attacks 5.7.7. Denial-of-Service Attacks
A signaling protocol SHOULD provide prevention of Denial-of-service A signaling protocol SHOULD provide prevention of Denial-of-service
attacks. To effectively prevent denial-of-service attacks it is attacks. To effectively prevent denial-of-service attacks it is
necessary that the used security and protocol mechanisms MUST have necessary that the used security and protocol mechanisms MUST have
low computational complexity to verify a state setup request prior to low computational complexity to verify a state setup request prior to
authenticating the requesting entity. Additionally the signaling authenticating the requesting entity. Additionally the signaling
protocol and the used security mechanisms SHOULD NOT require large protocol and the used security mechanisms SHOULD NOT require large
resource consumption on NSIS Entities (for example main memory or resource consumption on NSIS Entities (for example main memory or
other additional message exchanges) before a successful other additional message exchanges) before a successful
authentication is done. authentication is 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. Since the the identities and the content of the signaling messages. Since the
ability to listen to signaling channels is a major guide to what ability to listen to signaling channels is a major guide to what data
data channels are interesting ones. channels are interesting ones.
To prevent this from happening, confidentiality of the signaling To prevent this from happening, confidentiality of the signaling
message in a hop-by-hop manner SHOULD be provided. Note that most message in a hop-by-hop manner SHOULD be provided. Note that most
messages must be protected on a hop-by-hop basis, since entities, messages must be protected on a hop-by-hop basis, since entities,
which actively participate in the signaling protocol, must be able which actively participate in the signaling protocol, must be able to
to read and eventually modify the signaling messages. read and eventually modify the signaling messages.
5.7.9 Ownership of state 5.7.9. Ownership of State
When existing states have to be modified then there is a need to use When existing states have to be modified then there is a need to use
a session identifier to uniquely identify the established state. A a session identifier to uniquely identify the established state. A
signaling protocol MUST provide means of security protection to signaling protocol MUST provide means of security protection to
prevent adversaries from modifying state. prevent adversaries from modifying state.
5.8 Mobility 5.8. Mobility
5.8.1 Allow efficient service 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 states may need to be completely or partially re- handover, the states 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
the mobile node does not experience service interruption or service 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
require end-to-end signaling. require end-to-end signaling.
5.9 Interworking with other protocols and techniques 5.9. Interworking with Other Protocols and Techniques
Hooks SHOULD be provided to enable efficient interworking between Hooks SHOULD be provided to enable efficient interworking between
various protocols and techniques including the following listed. various protocols and techniques including the following listed.
5.9.1 MUST interwork with IP tunneling 5.9.1. MUST Interwork with IP Tunneling
IP tunneling for various applications MUST be supported. More IP tunneling for various applications MUST be supported. More
specifically IPSec tunnels are of importance. This mainly impacts specifically IPSec tunnels are of importance. This mainly impacts
the identification of flows. When using IPSec, parts of information the identification of flows. When using IPSec, parts of information
commonly used for flow identification (e.g. transport protocol commonly used for flow identification (e.g., transport protocol
information and ports) may not be accessible due to encryption. information and ports) may not be accessible due to encryption.
5.9.2 MUST NOT constrain either to IPv4 or IPv6 5.9.2. 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 NSIS SHOULD be developed with respect to be able to collect The NSIS protocol SHOULD be developed with respect to be able to
usage records from one or more network elements. collect usage records from one or more network elements.
5.9.5 SHOULD work with seamless handoff protocols 5.9.5. SHOULD Work with Seamless Handoff Protocols
An NSIS protocol SHOULD work with seamless handoff protocols such as An NSIS protocol SHOULD work with seamless handoff protocols such as
context transfer and candidate access router (CAR) discovery. context transfer and candidate access router (CAR) discovery.
5.9.6 MUST work with traditional routing 5.9.6. MUST Work with Traditional Routing
NSIS assumes traditional L3 routing, which is purely based on L3 NSIS assumes traditional L3 routing, which is purely based on L3
destination addresses. NSIS MUST work with L3 routing, in particular destination addresses. NSIS MUST work with L3 routing, in particular
it MUST work in case of route changes. This means state on the old it MUST work in case of route changes. This means state on the old
route MUST be released and state on the new route MUST be route MUST be released and state on the new route MUST be established
established by an NSIS protocol. by an NSIS protocol.
Networks, which do non-traditional routing, should not break NSIS Networks, which do non-traditional routing, should not break NSIS
signaling. NSIS MAY work for some of these situations. Particularly, signaling. NSIS MAY work for some of these situations.
combinations of NSIS unaware nodes and routing other then Particularly, combinations of NSIS unaware nodes and routing other
traditional one causes some problems. Non-traditional routing then traditional one causes some problems. Non-traditional routing
includes for example routing decisions based on port numbers, other includes, for example, routing decisions based on port numbers, other
IP header fields than the destination address, or splitting traffic IP header fields than the destination address, or splitting traffic
based on header hash values. These routing environments result in based on header hash values. These routing environments result in
the signaling path being potentially different than the data path. the signaling path being potentially different than the data path.
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
The NSIS architecture SHOULD allow the network operator to assign The NSIS architecture SHOULD allow the network operator to assign the
the NSIS protocol messages a certain transport quality. As signaling NSIS protocol messages a certain transport quality. As signaling
opens up for possible denial-of-service attacks, this requirement opens up the possibility of denial-of-service attacks, this
gives the network operator a means, but also the obligation, to requirement gives the network operator a means, but also the
trade-off between signaling latency and the impact (from the obligation, to trade-off between signaling latency and the impact
signaling messages) on devices within the network. From protocol (from the signaling messages) on devices within the network. From
design this requirement states that the protocol messages SHOULD be protocol design this requirement states that the protocol messages
detectable, at least where the control and assignment of the SHOULD be detectable, at least where the control and assignment of
messages priority is done. the messages priority is done.
Furthermore, the protocol design must take into account reliability Furthermore, the protocol design must take into account reliability
concerns. Communication reliability is seen as part of the quality concerns. Communication reliability is seen as part of the quality
assigned to signaling messages. So procedures MUST be defined how an assigned to signaling messages. So procedures MUST be defined for
NSIS signaling system behaves if some kind of request it sent stays how an NSIS signaling system behaves if some kind of request it sent
unanswered. The basic transport protocol to be used between adjacent stays unanswered. The basic transport protocol to be used between
NSIS Entities MAY ensure message integrity and reliable transport. adjacent NSIS Entities MAY ensure message integrity and reliable
transport.
5.10.2 Graceful fail over 5.10.2. Graceful Fail Over
Any unit participating in NSIS signaling MUST NOT cause further Any unit participating in NSIS signaling MUST NOT cause further
damage to other systems involved in NSIS signaling when it has to go damage to other systems involved in NSIS signaling when it has to go
out of service. out of service.
5.10.3 Graceful handling of NSIS entity problems 5.10.3. Graceful Handling of NSIS Entity Problems
NSIS entities SHOULD be able to detect a malfunctioning peer. It may NSIS entities SHOULD be able to detect a 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
is needed. needed.
6 Security Considerations 6. Security Considerations
Section 5.7 of this document provides security related requirements Section 5.7 of this document provides security related requirements
of a signaling protocol. of a signaling protocol.
7 References 7. Acknowledgments
7.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2 Non-Normative References
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
"Resource Protocol (RSVP) -- Version 1 Functional Specification",
RFC 2205, September 1997.
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[RFC3234] B. Carpenter, S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.
[PPVPN_FW] R. Callon, M. Suzuki, "A Framework for Layer 3 Provider
Provisioned Virtual Private Networks", <draft-ietf-ppvpn-framework-
08.txt>, March 2003
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
document, adding some ideas, requirements, etc. We list them without document, adding some ideas, requirements, etc. We list them without
a 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
Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical 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 an Internet Draft written by the following authors: David taken from an Internet Draft written by the following authors: David
Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis
(Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University of
of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars 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 this document as well. actively contributed new text to this document as well.
Another Internet Draft impacting this document has been written by Another Internet Draft impacting this document has been written by
Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel). Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel).
These people contributed also new text. These people contributed also new text.
Thanks also to Kwok Ho Chan (Nortel) for text changes. And finally Thanks also to Kwok Ho Chan (Nortel) for text changes. And finally
thanks Alison Mankin for the thorough AD review and thanks to Harald thanks Alison Mankin for the thorough AD review and thanks to Harald
Tveit Alvestrand and Steve Bellovin for the IESG review comments. Tveit Alvestrand and Steve Bellovin for the IESG review comments.
9 Author's Addresses 8. Appendix: Scenarios/Use Cases
Marcus Brunner (Editor)
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
D-69115 Heidelberg
Germany
E-Mail: brunner@ccrle.nec.de
Robert Hancock
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
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
Siemens AG
Berlin 13623
Germany
E-Mail: cornelia.kappler@icn.siemens.de
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munchen
Germany
Email: Hannes.Tschofenig@mchp.siemens.de
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,
cover, and which allow us to discuss various requirements. Some and which allow us to discuss various requirements. Some regard this
regard this as use cases to be covered defining the use of a as use cases to be covered defining the use of a signaling protocol.
signaling protocol. In general, these scenarios consider the In general, these scenarios consider the specific case of signaling
specific case of signaling for QoS (resource reservation), although for QoS (resource reservation), although many of the issues carry
many of the issues carry over directly to other signaling types. over directly to other signaling types.
10.1 Terminal Mobility 8.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, and communication partners access points, an access network manager, and communication partners
of the MT (the other end(s) of the communication association). of the MT (the other end(s) of the communication association). From
From a technical point of view, terminal mobility means changing the 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 change from e.g. a DiffServ to an IntServ domain, handoff, one changes 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
to change the access point, since the traffic conditions of the new decide to change the access point, since the traffic conditions of
access point are better supporting the QoS requirements. The metric the new access point are better supporting the QoS requirements.
may be different (optimized towards a single or a group/class of The metric may be different (optimized towards a single or a
users). Note that the MT or the network (see below) might trigger group/class of users). Note that the MT or the network (see
the handoff. below) might trigger the handoff.
- 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
granted (e.g. emptied prepaid condition). Or another example is when longer granted (e.g., emptied prepaid condition). Or another
the MT is reaching the focus of another base station. However, this example is when the MT is reaching the focus of another base
might be detected via measurements of QoS on the physical layer and station. However, this might be detected via measurements of QoS
is therefore out of scope of QoS signaling in IP. Note again that on the physical layer and is therefore out of scope of QoS
the MT or the network (see below) might trigger the handoff. signaling in IP. Note again that 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 do not only considered as well. Hand-off decisions in a QoS domain do not
depend on the local resource availability, e.g., the wireless part, only depend on the local resource availability, e.g., the wireless
but involve the rest of the path as well. Additionally, part, but involve the rest of the path as well. Additionally,
decomposition of an end-to-end signaling might be needed, in order decomposition of an end-to-end signaling 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
that two different provider networks are involved. Another important case that two different provider networks are involved. Another
example is when the current access point bearer disappears (e.g. important example is when the current access point bearer
removing the Ethernet cable). In this case, the NSIS Initiator is disappears (e.g., removing the Ethernet cable). In this case, the
basically located on the mobile terminal. NSIS Initiator is 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
load situation. Most likely this will result in changing the base- load situation. Most likely this will result in changing the
station of a single providers network. Most likely the NSIS base-station of a single providers network. Most likely the NSIS
Initiator is located on a system within the network. Initiator is located on a system within the network.
3) Integration with other protocols 3) Integration with other protocols
- Interworking with other protocol must be considered in one or the - Interworking with other protocol must be considered in one or the
other form. E.g., it might be worth combining QoS signaling between other form. E.g., it might be worth combining QoS signaling
different QoS domains with mobility signaling at hand-over. between different QoS domains with mobility signaling at hand-
over.
4) Handover rates 4) Handover rates
In mobile networks, the admission control process has to cope with In mobile networks, the admission control process has to cope with
far more admission requests than call setups alone would generate. far more admission requests than call setups alone would generate.
For example, in the GSM (Global System for Mobile communications) For example, in the GSM (Global System for Mobile communications)
case, mobility usually generates an average of one to two handovers case, mobility usually generates an average of one to two handovers
per call. For third generation networks (such as UMTS), where it is per call. For third generation networks (such as UMTS), where it is
necessary to keep radio links to several cells simultaneously necessary to keep radio links to several cells simultaneously
(macro-diversity), the handover rate is significantly higher. (macro-diversity), the handover rate is significantly higher.
skipping to change at page 25, line 9 skipping to change at page 28, line 22
new base station. In this situation, some packets might be new base station. In this situation, some packets might be
discarded, and the overall speech quality might be degraded discarded, and the overall speech quality might be degraded
significantly. Moreover, a delay in handover may cause degradation significantly. Moreover, a delay in handover may cause degradation
for other users. In the worst-case scenario, a delay in handover may for other users. In the worst-case scenario, a delay in handover may
cause the connection to be dropped if the handover occurred due to cause the connection to be dropped if the handover occurred due to
bad air link quality. Therefore, it is critical that QoS signaling bad air link quality. Therefore, it is critical that QoS signaling
in connection with handover be carried out very quickly. in connection with handover be carried out very quickly.
6) Call blocking in case of overload 6) Call blocking in case of overload
Furthermore, when the network is overloaded, it is preferable to Furthermore, when the network is overloaded, it is preferable to keep
keep s for previously established flows while blocking new requests. states for previously established flows while blocking new requests.
Therefore, the resource reservation requests in connection with Therefore, the resource reservation requests in connection with
handover should be given higher priority than new requests for handover should be given higher priority than new requests for
resource reservation. resource reservation.
10.2 Wireless Networks 8.2. Wireless Networks
In this scenario, the user is using the packet services of a In this scenario, the user is using the packet services of a wireless
wireless system (such as the 3rd generation wireless system system (such as the 3rd generation wireless system 3GPP/UMTS,
3GPP/UMTS, 3GPP2/cdma2000). The region between the End Host and the 3GPP2/cdma2000). The region between the End Host and the Edge Node
Edge Node (Edge Router) connecting the wireless network to another (Edge Router) connecting the wireless network to another QoS domain
QoS domain is considered to be a single QoS domain. is considered to be a single QoS domain.
The issues in such an environment regarding QoS include: The issues in such an environment regarding QoS include:
1) The wireless networks provide their own QoS technology with 1) The wireless networks provide their own QoS technology with
specialized parameters to co-ordinate the QoS provided by both the specialized parameters to coordinate the QoS provided by both the
radio access and wired access networks. Provisioning of QoS radio access and wired access networks. Provisioning of QoS
technologies within a wireless network can be described mainly in technologies within a wireless network can be described mainly in
terms of calling bearer classes, service options, and service terms of calling bearer classes, service options, and service
instances. These QoS technologies need to be invoked with suitable instances. These QoS technologies need to be invoked with
parameters when higher layers trigger a request for QoS. Therefore suitable parameters when higher layers trigger a request for QoS.
these involve mapping of the requested higher layer QoS parameters Therefore these involve mapping of the requested higher layer QoS
onto specific bearer classes or service instances. The request for parameters onto specific bearer classes or service instances. The
allocation of resources might be triggered by signaling at the IP request for allocation of resources might be triggered by
level that passes across the wireless system, and possibly other QoS signaling at the IP level that passes across the wireless system,
domains. Typically, wireless network specific messages are invoked and possibly other QoS domains. Typically, wireless network
to setup the underlying bearer classes or service instances in specific messages are invoked to setup the underlying bearer
parallel with the IP layer QoS negotiation, to allocate resources classes or service instances in parallel with the IP layer QoS
within the radio access network. negotiation, to allocate resources within the radio access
network.
2) The IP signaling messages are initiated by the NSIS initiator and 2) The IP signaling messages are initiated by the NSIS initiator and
interpreted by the NSIS Forwarder. The most efficient placement of interpreted by the NSIS Forwarder. The most efficient placement
the NSIS Initiator and NSIS Forwarder has not been determined in of the NSIS Initiator and NSIS Forwarder has not been determined
wireless networks, but a few potential scenarios can be envisioned. in wireless networks, but a few potential scenarios can be
The NSIS Initiator could be located at the End Host (e.g. 3G User envisioned. The NSIS Initiator could be located at the End Host
equipment (UE)), the Access Gateway or at a node that is not (e.g., 3G User equipment (UE)), the Access Gateway or at a node
directly on the data path, such as a Policy Decision Function. The that is not directly on the data path, such as a Policy Decision
Access Gateway could act as a proxy NSIS Initiator on behalf of the Function. The Access Gateway could act as a proxy NSIS Initiator
End Host. The Policy Decision Function that controls per- on behalf of the End Host. The Policy Decision Function that
flow/aggregate resources with respect to the session within its QoS controls per-flow/aggregate resources with respect to the session
domain (e.g. the 3G wireless network) may act as a proxy NSIS within its QoS domain (e.g., the 3G wireless network) may act as a
Initiator for the end host or the Access Gateway. Depending on the proxy NSIS Initiator for the end host or the Access Gateway.
placement of the NSIS Initiator, the NSIS Forwarder may be located Depending on the placement of the NSIS Initiator, the NSIS
at an appropriate point in the wireless network. Forwarder may be located at an appropriate point in the wireless
network.
3) The need for re-negotiation of resources in a new wireless domain 3) The need for re-negotiation of resources in a new wireless domain
due to host mobility. In this case the NSIS Initiator and the NSIS due to host mobility. In this case the NSIS Initiator and the
Forwarder should detect mobility events and autonomously trigger re- NSIS Forwarder should detect mobility events and autonomously
negotiation of resources. trigger re-negotiation of resources.
10.3 An example scenario for 3G wireless networks 8.3. An Example Scenario for 3G Wireless Networks
The following example is a pure hypothetical scenario, where an NSIS The following example is a pure hypothetical scenario, where an NSIS
signaling protocol might be used in a 3G environment. We do not signaling protocol might be used in a 3G environment. We do not
impose in any way, how a potential integration might be done. Terms impose in any way, how a potential integration might be done. Terms
from the 3GPP architecture are used (P-CSCF, IMS, expanded below) in from the 3GPP architecture are used (P-CSCF, IMS, expanded below) in
order to give specificity, but in a hypothetical design, one that order to give specificity, but in a hypothetical design, one that
reflects neither development nor review by 3GPP. The example should reflects neither development nor review by 3GPP. The example should
help in the design of a NSIS signaling protocol such that it could help in the design of a NSIS signaling protocol such that it could be
be used in various environments. used in various environments.
The 3G wireless access scenario is shown in Figure 1. The Proxy-Call The 3G wireless access scenario is shown in Figure 1. The Proxy-Call
State Control Function (P-CSCF) is the outbound SIP proxy (only used State Control Function (P-CSCF) is the outbound SIP proxy (only used
in integrated multimedia systems (IMS)). The Access Gateway is the in IP Multimedia Subsystems (IMS)). The Access Gateway is the egress
egress router of the 3G wireless domain and it connects the radio router of the 3G wireless domain and it connects the radio access
access network to the Edge Router (ER) of the backbone IP network. network to the Edge Router (ER) of the backbone IP network. The
The Policy Decision Function (PDF) is an entity responsible for Policy Decision Function (PDF) is an entity responsible for
controlling bearer level resource allocations/de-allocations in controlling bearer level resource allocations/de-allocations in
relation to session level services e.g. SIP. The Policy Decision relation to session level services e.g., SIP. The Policy Decision
Function may also control the Access Gateway to open and close the Function may also control the Access Gateway to open and close the
gates and to configure per-flow policies, i.e. to authorize or gates and to configure per-flow policies, i.e., to authorize or
forbid user traffic. The P-CSCF (only used in IMS) and the Access forbid user traffic. The P-CSCF (only used in IMS) and the Access
Gateway communicate with the Policy Decision Function, for network Gateway communicate with the Policy Decision Function, for network
resource allocation/de-allocation decisions. The User Equipment (UE) resource allocation/de-allocation decisions. The User Equipment (UE)
or the Mobile Station (MS) consists of a Mobile Terminal (MT) and or the Mobile Station (MS) consists of a Mobile Terminal (MT) and
Terminal Equipment (TE), e.g. a laptop. Terminal Equipment (TE), e.g., a laptop.
+--------+ +--------+
+--------->| P-CSCF |---------> SIP signaling +--------->| P-CSCF |---------> SIP signaling
/ +--------+ / +--------+
/ SIP | / SIP |
| | | |
| +-----+ +----------------+ | +-----+ +----------------+
| | PDF |<---------->| NSIS Forwarder |<---> | | PDF |<---------->| NSIS Forwarder |<--->
| +-----+ +----------------+ | +-----+ +----------------+
| | ^ | | ^
skipping to change at page 27, line 5 skipping to change at page 30, line 33
+------+ | Gateway |------------------| ER | +------+ | Gateway |------------------| ER |
+---------+ +----+ +---------+ +----+
Figure 1: 3G wireless access scenario Figure 1: 3G wireless access scenario
The PDF has all the required QoS information for per-flow or The PDF has all the required QoS information for per-flow or
aggregate admission control in 3G wireless networks. It receives aggregate admission control in 3G wireless networks. It receives
resource allocation/de-allocation requests from the P-CSCF and/or resource allocation/de-allocation requests from the P-CSCF and/or
Access Gateway etc. and responds with policy decisions. Hence the Access Gateway etc. and responds with policy decisions. Hence the
PDF may be a candidate entity to host the functionality of the NSIS PDF may be a candidate entity to host the functionality of the NSIS
Initiator, initiating the "NSIS" QoS signaling towards the backbone Initiator, initiating the NSIS QoS signaling towards the backbone IP
IP network. On the other hand, the UE/MS may act as the NSIS network. On the other hand, the UE/MS may act as the NSIS Initiator
Initiator or the Access Gateway may act as a Proxy NSIS Initiator on or the Access Gateway may act as a Proxy NSIS Initiator on behalf of
behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do the UE/MS. In the former case, the P-CSCF/PDF has to do the mapping
the mapping from codec types and media descriptors (derived from from codec types and media descriptors (derived from SIP/SDP
SIP/SDP signaling) to IP traffic descriptor. In the latter case, the signaling) to IP traffic descriptor. In the latter case, the UE/MS
UE/MS may use any appropriate QoS signaling mechanism as the NSIS may use any appropriate QoS signaling mechanism as the NSIS
Initiator. If the Access Gateway is acting as the Proxy NSIS Initiator. If the Access Gateway is acting as the Proxy NSIS
initiator on behalf of the UE/MS, then it may have to do the mapping initiator on behalf of the UE/MS, then it may have to do the mapping
of parameters from radio access specific QoS to IP QoS traffic of parameters from radio access specific QoS to IP QoS traffic
parameters before forwarding the request to the NSIS Forwarder. parameters before forwarding the request to the NSIS Forwarder.
The NSIS Forwarder is currently not part of the standard 3G wireless The NSIS Forwarder is currently not part of the standard 3G wireless
architecture. However, to achieve end-to-end QoS a NSIS Forwarder is architecture. However, to achieve end-to-end QoS a NSIS Forwarder is
needed such that the NSIS Initiators can request a QoS connection to needed such that the NSIS Initiators can request a QoS connection to
the IP network. As in the previous example, the NSIS Forwarder could the IP network. As in the previous example, the NSIS Forwarder could
manage a set of pre-provisioned resources in the IP network, i.e. manage a set of pre-provisioned resources in the IP network, i.e.,
bandwidth pipes, and the NSIS Forwarder perform per-flow admission bandwidth pipes, and the NSIS Forwarder perform per-flow admission
control into these pipes. In this way, a connection can be made control into these pipes. In this way, a connection can be made
between two 3G wireless access networks, and hence, end-to-end QoS between two 3G wireless access networks, and hence, end-to-end QoS
can be achieved. In this case the NSIS Initiator and NSIS Forwarder can be achieved. In this case the NSIS Initiator and NSIS Forwarder
are clearly two separate logical entities. The Access Gateway or/and are clearly two separate logical entities. The Access Gateway or/and
the Edge Router in Fig.1 may contain the NSIS Forwarder the Edge Router in Fig.1 may contain the NSIS Forwarder
functionality, depending upon the placement of the NSIS Initiator as functionality, depending upon the placement of the NSIS Initiator as
discussed in scenario 2 in section 10.2. This use case clearly discussed in scenario 2 in section 8.2. This use case clearly
illustrates the need for an NSIS QoS signaling protocol between NSIS illustrates the need for an NSIS QoS signaling protocol between NSIS
Initiator and NSIS Forwarder. An important application of such a Initiator and NSIS Forwarder. An important application of such a
protocol may be its use in the end-to-end establishment of a protocol may be its use in the end-to-end establishment of a
connection with specific QoS characteristics between a mobile host connection with specific QoS characteristics between a mobile host
and another party (e.g. end host or content server). and another party (e.g., end host or content server).
10.4 Wired part of wireless network 8.4. Wired Part of Wireless Network
A wireless network, seen from a QoS domain perspective, usually A wireless network, seen from a QoS domain perspective, usually
consists of three parts: a wireless interface part (the "radio consists of three parts: a wireless interface part (the "radio
interface"), a wired part of the wireless network (i.e., Radio interface"), a wired part of the wireless network (i.e., Radio Access
Access Network) and the backbone of the wireless network, as shown Network) and the backbone of the wireless network, as shown in Figure
in Figure 2. Note that this figure should not be seen as an 2. Note that this figure should not be seen as an architectural
architectural overview of wireless networks but rather as showing overview of wireless networks but rather as showing the conceptual
the conceptual QoS domains in a wireless network. QoS domains in a wireless network.
In this scenario, a mobile host can roam and perform a handover In this scenario, a mobile host can roam and perform a handover
procedure between base stations/access routers. In this scenario the procedure between base stations/access routers. In this scenario the
NSIS QoS protocol can be applied between a base station and the NSIS QoS protocol can be applied between a base station and the
gateway (GW). In this case a GW can also be considered as a local gateway (GW). In this case a GW can also be considered as a local
handover anchor point. Furthermore, in this scenario the NSIS QoS handover anchor point. Furthermore, in this scenario the NSIS QoS
protocol can also be applied either between two GWs, or between two protocol can also be applied either between two GWs, or between two
edge routers (ER). edge routers (ER).
|--| |--|
skipping to change at page 28, line 33 skipping to change at page 32, line 33
Wired part of wireless network Wired part of wireless network
<----------------------------------------> <---------------------------------------->
Wireless Network Wireless Network
Figure 2. QoS architecture of wired part of wireless network Figure 2. QoS architecture of wired part of wireless network
Each of these parts of the wireless network impose different issues Each of these parts of the wireless network impose different issues
to be solved on the QoS signaling solution being used: to be solved on the QoS signaling solution being used:
- Wireless interface: The solution for the air interface link 1) Wireless interface: The solution for the air interface link has to
has to ensure flexibility and spectrum efficient transmission ensure flexibility and spectrum efficient transmission of IP
of IP packets. However, this link layer QoS can be solved in packets. However, this link layer QoS can be solved in the same
the same way as any other last hop problem by allowing a way as any other last hop problem by allowing a host to request
host to request the proper QoS profile. the proper QoS profile.
- Wired part of the wireless network: This is the part of 2) Wired part of the wireless network: This is the part of the
the network that is closest to the base stations/access network that is closest to the base stations/access routers. It
routers. It is an IP network although some parts logically is an IP network although some parts logically perform tunneling
perform tunneling of the end user data. In cellular networks, of the end user data. In cellular networks, the wired part of the
the wired part of the wireless network is denoted as a wireless network is denoted as a radio access network.
radio access network.
This part of the wireless network has different This part of the wireless network has different requirements for
characteristics when compared to traditional IP networks: signaling protocol characteristics when compared to traditional IP
networks:
1. The network must support mobility. Many wireless - The network must support mobility. Many wireless networks are
networks are able to provide a combination of soft able to provide a combination of soft and hard handover
and hard handover procedures. When handover occurs, procedures. When handover occurs, reservations need to be
reservations need to be established on new paths. established on new paths. The establishment time has to be as
The establishment time has to be as short as possible short as possible since long establishment times for s degrade
since long establishment times for s degrade the performance of the wireless network. Moreover, for maximal
the performance of the wireless network. Moreover, utilization of the radio spectrum, frequent handover operations
for maximal utilization of the radio spectrum, frequent are required.
handover operations are required.
2. These links are typically rather bandwidth-limited. - These links are typically rather bandwidth-limited.
3. The wired transmission in such a network contains a - The wired transmission in such a network contains a relatively
relatively high volume of expensive leased lines. high volume of expensive leased lines. Overprovisioning might
Overprovisioning might therefore be prohibitively therefore be prohibitively expensive.
expensive.
4. The radio base stations are spread over a wide - The radio base stations are spread over a wide geographical
geographical area and are in general situated a large area and are in general situated a large distance from the
distance from the backbone. backbone.
- Backbone of the wireless network: the requirements imposed 3) Backbone of the wireless network: the requirements imposed by this
by this network are similar to the requirements imposed by network are similar to the requirements imposed by other types of
other types of backbone networks. backbone networks.
Due to these very different characteristics and requirements, often Due to these very different characteristics and requirements, often
contradictory, different QoS signaling solutions might be needed in contradictory, different QoS signaling solutions might be needed in
each of the three network parts. each of the three network parts.
10.5 Session Mobility 8.5. Session Mobility
In this scenario, a session is moved from one end-system to another. In this scenario, a session is moved from one end-system to another.
Ongoing sessions are kept and QoS parameters need to be adapted, Ongoing sessions are kept and QoS parameters need to be adapted,
since it is very likely that the new device provides different since it is very likely that the new device provides different
capabilities. Note that it is open which entity initiates the move, capabilities. Note that it is open which entity initiates the move,
which implies that the NSIS Initiator might be triggered by which implies that the NSIS Initiator might be triggered by different
different entities. entities.
User mobility (i.e., a user changing the device and therefore moving User mobility (i.e., a user changing the device and therefore moving
the sessions to the new device) is considered to be a special case the sessions to the new device) is considered to be a special case
within the session mobility scenario. within the session mobility scenario.
Note that this scenario is different from terminal mobility. Not the Note that this scenario is different from terminal mobility. The
terminal (end-system) has moved to a different access point. Both terminal (end-system) has not moved to a different access point.
terminals are still connected to an IP network at their original Both terminals are still connected to an IP network at their original
points. points.
The issues include: The issues include:
1) Keeping the QoS guarantees negotiated implies that the end- 1) Keeping the QoS guarantees negotiated implies that the end-
point(s) of communication are changed without changing the s. point(s) of communication are changed without changing the s.
2) The trigger of the session move might be the user or any other 2) The trigger of the session move might be the user or any other
party involved in the session. party involved in the session.
10.6 QoS reservation/negotiation from access to core network 8.6. QoS Reservation/Negotiation from Access to Core Network
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 s might be different (long living s of 2) The time scales of states might be different (long living states
aggregates, less often re-negotiation). 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
particular QoS is guaranteed for, needs to be changed. E.g., in case 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
addresses and sets of different address for the source as well as and sets of different address for the source as well as for the
for the destination of the flow. destination of the flow.
10.7 QoS reservation/negotiation over administrative boundaries 8.7. QoS Reservation/Negotiation Over Administrative Boundaries
Signaling between two or more core networks to provide QoS is Signaling between two or more core networks to provide QoS is handled
handled in this scenario. This might also include access to core in this scenario. This might also include access to core signaling
signaling over administrative boundaries. Compared to the previous over administrative boundaries. Compared to the previous one it adds
one it adds the case, where the two networks are not in the same the case, where the two networks are not in the same administrative
administrative domain. Basically, it is the inter-domain/inter domain. Basically, it is the inter-domain/inter-provider signaling
provider signaling which is handled in here. which is handled in here.
The domain boundary is the critical issue to be resolved. Which as The domain boundary is the critical issue to be resolved. Which of
various flavors of issues a QoS signaling protocol has to be various flavors of issues a QoS signaling protocol has to be
concerned with. concerned with.
1) Competing administrations: Normally, only basic information 1) Competing administrations: Normally, only basic information should
should be exchanged, if the signaling is between competing be exchanged, if the signaling is between competing
administrations. Specifically information about core network administrations. Specifically information about core network
internals (e.g., topology, technology, etc.) should not be internals (e.g., topology, technology, etc.) should not be
exchanged. Some information exchange about the "access points" of exchanged. Some information exchange about the "access points" of
the core networks (which is topology information as well) may need the core networks (which is topology information as well) may be
to be exchanged, because it is needed for proper signaling. required, to be exchanged, because it is needed for proper
signaling.
2) Additionally, as in scenario 4, signaling most likely is based on 2) Additionally, as in scenario 4, signaling most likely is based on
aggregates, with all the issues raise there. aggregates, with all the issues raise there.
3) Authorization: It is critical that the NSIS Initiator is 3) Authorization: It is critical that the NSIS Initiator is
authorized to perform a QoS path setup. authorized to perform a QoS path setup.
4) Accountability: It is important to notice that signaling might be 4) Accountability: It is important to notice that signaling might be
used as an entity to charge money for, therefore the interoperation used as an entity to charge money for, therefore the
with accounting needs to be available. interoperation with accounting needs to be available.
10.8 QoS signaling between PSTN gateways and backbone routers 8.8. QoS Signaling Between PSTN Gateways and Backbone Routers
A PSTN gateway (i.e., host) requires information from the network A PSTN gateway (i.e., host) requires information from the network
regarding its ability to transport voice traffic across the network. regarding its ability to transport voice traffic across the network.
The voice quality will suffer due to packet loss, latency and The voice quality will suffer due to packet loss, latency and jitter.
jitter. Signaling is used to identify and admit a flow for which Signaling is used to identify and admit a flow for which these
these impairments are minimized. In addition, the disposition of impairments are minimized. In addition, the disposition of the
the signaling request is used to allow the PSTN GW to make a call signaling request is used to allow the PSTN GW to make a call routing
routing decision before the call is actually accepted and delivered decision before the call is actually accepted and delivered to the
to the final destination. final destination.
PSTN gateways may handle thousands of calls simultaneously and there PSTN gateways may handle thousands of calls simultaneously and there
may be hundreds of PSTN gateways in a single provider network. These may be hundreds of PSTN gateways in a single provider network. These
numbers are likely to increase as the size of the network increases. numbers are likely to increase as the size of the network increases.
The point being that scalability is a major issue. The point being that scalability is a major issue.
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
that has a global view of the network and its resources. 2. Handling admission control through some policy server 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
the 5-tuple used to carry a single RTP flow). 4. Per call admission control (where a call is defined as 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
scaling properties, however, its scaling properties only are scaling properties, however, its scaling properties only are
effective in cases where there are relatively few PSTN GWs. In the effective in cases where there are relatively few PSTN GWs. In the
more general case were a PSTN GW reduces to a single IP phone more general case where a PSTN GW reduces to a single IP phone
sitting behind some access network, the opportunities for sitting behind some access network, the opportunities for aggregation
aggregation are reduced and the problem reduces to item 4. are reduced and the problem reduces to item 4.
Item 4 is the most general case. However, it has the most difficult Item 4 is the most general case. However, it has the most difficult
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
points allows the inclusion of IP phones on cable, DSL, wireless or allows the inclusion of IP phones on cable, DSL, wireless or other
other access networks in this scenario. 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
skipping to change at page 32, line 21 skipping to change at page 36, line 41
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 8.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)
(ER) will be the NSIS Forwarder. Hence, the ER should do will be the NSIS Forwarder. Hence, the ER should do admission
admission control (into pre-provisioned traffic trunks) for the control (into pre-provisioned traffic trunks) for the individual
individual traffic flows. This scenario is not further 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 Media Gateway Controller (MGC). In this case no
required. NSIS protocol is required.
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 3. Out-of-band signaling in a single domain, the NSIS forwarder is a
MGC and the NSIS Forwarder. separate box. In this case NSIS signaling is used between the MGC
4. Out-of-band signaling between multiple domains, the NSIS and the NSIS Forwarder.
Forwarder (which may be integrated in the MGC) triggers the
NSIS Forwarder of the next domain. 4. Out-of-band signaling between multiple domains, the NSIS Forwarder
(which may be integrated in the MGC) triggers the 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
trunks that are leased from a network provider. The MGC does the trunks that are leased from a network provider. The MGC does the
admission control in this case. Since the NSIS Forwarder acts both admission control in this case. Since the NSIS Forwarder acts both
as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is
required. This scenario is shown in Figure 3. required. This scenario is shown in Figure 3.
skipping to change at page 34, line 9 skipping to change at page 38, line 42
In the fourth scenario multiple transport domains are involved. In In the fourth scenario multiple transport domains are involved. In
the originating network either the MGC may have an overview on the the originating network either the MGC may have an overview on the
resources of the overlay network or a separate NSIS Forwarder will resources of the overlay network or a separate NSIS Forwarder will
have the overview. Hence, depending on this either the MGC or the have the overview. Hence, depending on this either the MGC or the
NSIS Forwarder of the originating domain will contact the NSIS NSIS Forwarder of the originating domain will contact the NSIS
Forwarder of the next domain. The MGC always acts as a NSIS Forwarder of the next domain. The MGC always acts as a NSIS
Initiator and may also be acting as a NSIS Forwarder in the first Initiator and may also be acting as a NSIS Forwarder in the first
domain. domain.
10.10 An application requests end-to-end QoS path from the network 8.10. An Application Requests End-to-End QoS Path from the Network
This is actually the conceptually simplest case. So a multimedia This is actually the conceptually simplest case. A multimedia
application requests a guaranteed service from an IP network. We application requests a guaranteed service from an IP network. We
assume here that the application is somehow able to specify the assume here that the application is somehow able to specify the
network service. The characteristics here are that many hosts might network service. The characteristics here are that many hosts might
do it, but that the requested service is low capacity (bounded by do it, but that the requested service is low capacity (bounded by the
the access line). Note that there is an issue of scaling in the access line). Note that there is an issue of scaling in the number
number of applications requesting this service in the core of the of applications requesting this service in the core of the network.
network.
10.11 QOS for Virtual Private Networks 8.11. QOS for Virtual Private Networks
In a Virtual Private Network (VPN) [PPVPN_FW] a variety of tunnels In a Virtual Private Network (VPN), a variety of tunnels might be
might be used between its edges. These tunnels could be for example, used between its edges. These tunnels could be for example, IPSec,
IPSec, GRE, and IP-IP. One of the most significant issues in VPNs is GRE, and IP-IP. One of the most significant issues in VPNs is
related to how a flow is identified and what quality a flow gets. A related to how a flow is identified and what quality a flow gets. A
flow identification might consist among others of the transport flow identification might consist among others of the transport
protocol port numbers. In an IP-Sec tunnel this will be problematic protocol port numbers. In an IP-Sec tunnel this will be problematic
since the transport protocol information is encrypted. since the transport protocol information is encrypted.
There are two types of L3 VPNs, distinguished by where the endpoints There are two types of L3 VPNs, distinguished by where the endpoints
of the tunnels exist. The endpoints of the tunnels may either be on of the tunnels exist. The endpoints of the tunnels may either be on
the customer (CPE) or the provider equipment or provider edge (PE). the customer (CPE) or the provider equipment or provider edge (PE).
Virtual Private networks are also likely to request bandwidth or Virtual Private networks are also likely to request bandwidth or
other type of service in addition to the premium services the PSTN other type of service in addition to the premium services the PSTN GW
GW are likely to use. are likely to use.
10.11.1 Tunnel end points at the Customer premises 8.11.1. Tunnel End Points at the Customer Premises
When the endpoints are the CPE, the CPE may want to signal across When the endpoints are the CPE, the CPE may want to signal across the
the public IP network for a particular amount of bandwidth and QoS public IP network for a particular amount of bandwidth and QoS for
for the tunnel aggregate. Such signaling may be useful when a the tunnel aggregate. Such signaling may be useful when a customer
customer wants to vary their network cost with demand, rather than wants to vary their network cost with demand, rather than paying a
paying a flat rate. Such signaling exists between the two CPE flat rate. Such signaling exists between the two CPE routers.
routers. Intermediate access and edge routers perform the same exact Intermediate access and edge routers perform the same exact call
call admission control, authentication and aggregation functions admission control, authentication and aggregation functions performed
performed by the corresponding routers in the PSTN GW scenario with by the corresponding routers in the PSTN GW scenario with the
the exception that the endpoints are the CPE tunnel endpoints rather exception that the endpoints are the CPE tunnel endpoints rather than
than PSTN GWs and the 5-tuple used to describe the RTP flow is PSTN GWs and the 5-tuple used to describe the RTP flow is replaced
replaced with the corresponding flow spec to uniquely identify the with the corresponding flow spec to uniquely identify the tunnels.
tunnels. Tunnels may be of any variety (e.g. IP-Sec, GRE, IP-IP). Tunnels may be of any variety (e.g., IP-Sec, GRE, IP-IP).
In such a scenario, NSIS would actually allow partly for customer In such a scenario, NSIS would actually allow partly for customer
managed VPNs, which means a customer can setup VPNs by subsequent managed VPNs, which means a customer can setup VPNs by subsequent
NSIS signaling to various end-point. Plus the tunnel end-points are NSIS signaling to various end-point. Plus the tunnel end-points are
not necessarily bound to an application. The customer administrator not necessarily bound to an application. The customer administrator
might be the one triggering NSIS signaling. might be the one triggering NSIS signaling.
10.11.2 Tunnel end points at the provider premises 8.11.2. Tunnel End Points at the Provider Premises
In the case were the tunnel end-points exist on the provider edge, In the case were the tunnel end-points exist on the provider edge,
requests for bandwidth may be signaled either per flow, where a flow requests for bandwidth may be signaled either per flow, where a flow
is defined from a customers address space, or between customer is defined from a customers address space, or between customer sites.
sites.
In the case of per flow signaling, the PE router must map the In the case of per flow signaling, the PE router must map the
bandwidth request to the tunnel carrying traffic to the destination bandwidth request to the tunnel carrying traffic to the destination
specified in the flow spec. Such a tunnel is a member of an specified in the flow spec. Such a tunnel is a member of an
aggregate to which the flow must be admitted. In this case, the aggregate to which the flow must be admitted. In this case, the
operation of admission control is very similar to the case of the operation of admission control is very similar to the case of the
PSTN GW with the additional level of indirection imposed by the VPN PSTN GW with the additional level of indirection imposed by the VPN
tunnel. Therefore, authentication, accounting and policing may be tunnel. Therefore, authentication, accounting and policing may be
required on the PE router. required on the PE router.
In the case of per site signaling, a site would need to be In the case of per site signaling, a site would need to be
identified. This may be accomplished by specifying the network identified. This may be accomplished by specifying the network
serviced at that site through an IP prefix. In this case, the serviced at that site through an IP prefix. In this case, the
admission control function is performed on the aggregate to the PE admission control function is performed on the aggregate to the PE
router connected to the site in question. router connected to the site in question.
Full Copyright Statement 9. References
Copyright (C) The Internet Society (2003). All Rights Reserved. 9.1. Normative References
This document and translations of it may be copied and furnished to [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
others, and derivative works that comment on or otherwise explain it Requirement Levels", BCP 14, RFC 2119, March 1997.
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be 9.2. Informative References
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an [RSVP] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Jamin, "Resource Protocol (RSVP) -- Version 1 Functional
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Specification", RFC 2205, September 1997.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Issues", RFC 3234, February 2002.
10. Authors' Addresses
Marcus Brunner (Editor)
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
D-69115 Heidelberg
Germany
EMail: brunner@netlab.nec.de
Robert Hancock
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
EMail: robert.hancock@roke.co.uk
Eleanor Hepworth
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
EMail: eleanor.hepworth@roke.co.uk
Cornelia Kappler
Siemens AG
Berlin 13623
Germany
EMail: cornelia.kappler@siemens.com
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munchen
Germany
EMail: Hannes.Tschofenig@mchp.siemens.de
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Notices
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made Copies of IPR disclosures made to the IETF Secretariat and any
to obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification attempt made to obtain a general license or permission for the use of
can be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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