draft-ietf-nsis-req-08.txt   draft-ietf-nsis-req-09.txt 
Network Working Group M. Brunner (Editor) Network Working Group M. Brunner (Editor)
Internet Draft NEC Internet Draft NEC
Category: Informational June 2003 Category: Informational August 2003
Requirements for Signaling Protocols Requirements for Signaling Protocols
<draft-ietf-nsis-req-08.txt> <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 document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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 domains. Signaling is mainly considered for Quality of technology domains. Signaling is mainly considered for Quality of
Service such as The Resource Reservation Protocol, however in recent Service such as The Resource Reservation Protocol, however in recent
years several other applications of signaling have been defined such years several other applications of signaling have been defined such
as signaling for label distribution in Multiprotocol Label Switching as signaling for label distribution in Multiprotocol Label Switching
or signaling to middleboxes. To achieve wide applicability of the or signaling to middleboxes. To achieve wide applicability of the
skipping to change at page 2, line 27 skipping to change at page 2, line 27
5 Requirements.....................................................9 5 Requirements.....................................................9
5.1 Architecture and Design Goals..................................9 5.1 Architecture and Design Goals..................................9
5.1.1 NSIS SHOULD provide availability information on request......9 5.1.1 NSIS SHOULD provide availability information on request......9
5.1.2 NSIS MUST be designed modularly..............................9 5.1.2 NSIS MUST be designed modularly..............................9
5.1.3 NSIS MUST decouple protocol and information.................10 5.1.3 NSIS MUST decouple protocol and information.................10
5.1.4 NSIS MUST support independence of signaling and network 5.1.4 NSIS MUST support independence of signaling and network
control paradigm..................................................10 control paradigm..................................................10
5.1.5 NSIS SHOULD be able to carry opaque objects.................10 5.1.5 NSIS SHOULD be able to carry opaque objects.................10
5.2 Signaling Flows...............................................10 5.2 Signaling Flows...............................................10
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...........................11 anywhere in the network MUST be allowed...........................10
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.........................................................11 signaling.........................................................11
5.2.3 Concealment of topology and technology information SHOULD be 5.2.3 Concealment of topology and technology information SHOULD be
possible..........................................................11 possible..........................................................11
5.2.4 Transparent signaling through networks SHOULD be possible...11 5.2.4 Transparent signaling through networks SHOULD be possible...11
5.3 Messaging.....................................................11 5.3 Messaging.....................................................11
5.3.1 Explicit erasure of state MUST be possible..................12 5.3.1 Explicit erasure of state MUST be possible..................11
5.3.2 Automatic release of state after failure MUST be possible...12 5.3.2 Automatic release of state after failure MUST be possible...11
5.3.3 NSIS SHOULD allow for sending notifications upstream........12 5.3.3 NSIS SHOULD allow for sending notifications upstream........12
5.3.4 Establishment and refusal to set up state MUST be notified..13 5.3.4 Establishment and refusal to set up state MUST be notified..13
5.3.5 NSIS MUST allow for local information exchange..............13 5.3.5 NSIS MUST allow for local information exchange..............13
5.4 Control Information...........................................13 5.4 Control Information...........................................13
5.4.1 Mutability information on parameters SHOULD be possible.....14 5.4.1 Mutability information on parameters SHOULD be possible.....13
5.4.2 It SHOULD be possible to add and remove local domain 5.4.2 It SHOULD be possible to add and remove local domain
information.......................................................14 information.......................................................13
5.4.3 State MUST be addressed independent of flow identification..14 5.4.3 State MUST be addressed independent of flow identification..14
5.4.4 Modification of already established state SHOULD be seamless14 5.4.4 Modification of already established state SHOULD be seamless14
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
..................................................................14 ..................................................................14
5.5 Performance...................................................15 5.5 Performance...................................................14
5.5.1 Scalability.................................................15 5.5.1 Scalability.................................................15
5.5.2 NSIS SHOULD allow for low latency in setup..................15 5.5.2 NSIS SHOULD allow for low latency in setup..................15
5.5.3 NSIS MUST allow for low bandwidth consumption for the 5.5.3 NSIS MUST allow for low bandwidth consumption for the
signaling protocol................................................15 signaling protocol................................................15
5.5.4 NSIS SHOULD allow to constrain load on devices..............16 5.5.4 NSIS SHOULD allow to constrain load on devices..............16
5.5.5 NSIS SHOULD target the highest possible network utilization.16 5.5.5 NSIS SHOULD target the highest possible network utilization.16
5.6 Flexibility...................................................16 5.6 Flexibility...................................................16
5.6.1 Flow aggregation............................................16 5.6.1 Flow aggregation............................................16
5.6.2 Flexibility in the placement of the NSIS Initiator/Responder16 5.6.2 Flexibility in the placement of the NSIS Initiator/Responder16
5.6.3 Flexibility in the initiation of state change...............16 5.6.3 Flexibility in the initiation of state change...............16
skipping to change at page 3, line 19 skipping to change at page 3, line 19
5.7.4 Replay protection...........................................18 5.7.4 Replay protection...........................................18
5.7.5 Hop-by-hop security.........................................18 5.7.5 Hop-by-hop security.........................................18
5.7.6 Identity confidentiality and network topology hiding........18 5.7.6 Identity confidentiality and network topology hiding........18
5.7.7 Denial-of-service attacks...................................18 5.7.7 Denial-of-service attacks...................................18
5.7.8 Confidentiality of signaling messages.......................19 5.7.8 Confidentiality of signaling messages.......................19
5.7.9 Ownership of state..........................................19 5.7.9 Ownership of state..........................................19
5.8 Mobility......................................................19 5.8 Mobility......................................................19
5.8.1 Allow efficient service re-establishment after handover.....19 5.8.1 Allow efficient service re-establishment after handover.....19
5.9 Interworking with other protocols and techniques..............19 5.9 Interworking with other protocols and techniques..............19
5.9.1 MUST interwork with IP tunneling............................19 5.9.1 MUST interwork with IP tunneling............................19
5.9.2 MUST NOT constrain either to IPv4 or IPv6...................19 5.9.2 MUST NOT constrain either to IPv4 or IPv6...................20
5.9.3 MUST be independent from charging model.....................20 5.9.3 MUST be independent from charging model.....................20
5.9.4 SHOULD provide hooks for AAA protocols......................20 5.9.4 SHOULD provide hooks for AAA protocols......................20
5.9.5 SHOULD work with seamless handoff protocols.................20 5.9.5 SHOULD work with seamless handoff protocols.................20
5.9.6 MUST work with traditional routing..........................20 5.9.6 MUST work with traditional routing..........................20
5.10 Operational..................................................20 5.10 Operational..................................................20
5.10.1 Ability to assign transport quality to signaling messages..20 5.10.1 Ability to assign transport quality to signaling messages..20
5.10.2 Graceful fail over.........................................21 5.10.2 Graceful fail over.........................................21
5.10.3 Graceful handling of NSIS entity problems..................21 5.10.3 Graceful handling of NSIS entity problems..................21
6 Security Considerations.........................................21 6 Security Considerations.........................................21
7 References......................................................21 7 References......................................................21
skipping to change at page 6, line 33 skipping to change at page 6, line 33
or more IP hops. The underlying network might use locally different or 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 NSIS
Forwarder maps service-specific information to technology-related Forwarder maps service-specific information to technology-related
QoS parameters and receives indications about success or failure in QoS parameters and receives indications about success or failure in
response. 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 domain
contains one link). Domains are assumed to be administrative contains one link). Domains are assumed to be administrative
entities, so security requirements apply to the signaling between entities. So security requirements might apply differently for the
them. signaling between the domains and within a 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 the
other end of the network the signaling propagates. In general, we other end of the network the signaling propagates. In general, we
could expect NSIS Forwarders to become more 'dense' towards the could expect NSIS Forwarders to become more 'dense' towards the
skipping to change at page 9, line 17 skipping to change at page 9, line 21
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 framework, 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, information, and flexibility. security, information, and flexibility.
Two general (and potentially contradictory) goals for the solution Two general (and potentially contradictory) goals for the solution
are that it should be applicable in a very wide range of scenarios, are that it should be applicable in a very wide range of scenarios,
and at the same time lightweight in implementation complexity and and at the same time lightweight in implementation complexity and
resource consumption requirements in NSIS Entities. One approach to resource consumption requirements in NSIS Entities. We use the terms
this is that the solution could deal with certain requirements via 'access' and 'core' informally in the discussion of some particular
modular components or capabilities, which are optional to implement requirements to refer to deployment conditions where particular
or use in individual nodes. protocol attributes, especially performance characteristics, have
special importance. Specifically, 'access' refers to lower capacity
In order to prioritize the various requirements we informally define networks and fewer users and sessions. 'Core' refers to high
different 'parts of the network'. In the different parts of the capacity networks with a large number of users and sessions.
network a particular requirement might have a different priority.
The parts of the networks we differentiate are the host-to-first One approach to this is that the solution could deal with certain
router, the access network, and the core network. The host to first requirements via modular components or capabilities, which are
router part includes all the layer 2 technologies to access to the optional to implement or use in individual nodes.
Internet. This part of the division is especially informal and may
incorporate several access segments. In many cases, there is an
application and/or user running on the host initiating signaling.
The access network can be characterized by low capacity links,
medium speed IP processing capabilities, and it might consist of a
complete layer 2 network as well. The core network characteristics
include high-speed forwarding capacities and inter-domain issues.
These divisions between network types are not strict and do not
appear in all networks, but where they do exist they may influence
signaling requirements and will be highlighted as necessary.
5.1 Architecture and Design Goals 5.1 Architecture and Design Goals
This section contains requirements related to desirable overall This section contains requirements related to desirable overall
characteristics of a solution, e.g. enabling flexibility, or characteristics of a solution, e.g. enabling flexibility, or
independence of parts of the framework. independence of parts of the framework.
5.1.1 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
skipping to change at page 13, line 25 skipping to change at page 13, line 14
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.
.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 An 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 set up state. It MUST be sent to the NI. Depending on the to set up state. It MUST be sent to the NI. Depending on the
signaling application the (positive or negative) notifications may signaling application the (positive or negative) notifications may
have to pass through further NEs upstream. Information on the reason have to pass through further NEs upstream. Information on the reason
of the refusal to set up state MAY be made available. For example, of the refusal to set up state MAY be made available. For example,
in the resource reservation example, together with a negative in the resource reservation example, together with a negative
answer, the amount of resources available might also be returned. answer, the amount of resources available might also be returned.
skipping to change at page 15, line 44 skipping to change at page 15, line 34
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
the use of signaling by hosts becomes universal. Note that
requirement 5.2.4 requires the functionality of transparently
signaling through networks without interpretation. Additionally,
requirement 5.6.1 lists the capability to aggregate. Furthermore,
requirement 5.5.4 states that NSIS should be able to constrain the
load on devices. Basically, the performance of the signaling MUST
degrade gracefully rather than catastrophically under overload
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 delay). setup 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
skipping to change at page 19, line 11 skipping to change at page 19, line 11
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. To prevent the identities and the content of the signaling messages. Since the
this from happening, confidentiality of the signaling message in a ability to listen to signaling channels is a major guide to what
hop-by-hop manner MAY be provided. Note that the protection can be data channels are interesting ones.
provided on a hop-by-hop basis for most message payloads since it is
required that entities which actively participating in the signaling To prevent this from happening, confidentiality of the signaling
protocol must be able to read and eventually modify the content of message in a hop-by-hop manner SHOULD be provided. Note that most
the signaling messages. messages must be protected on a hop-by-hop basis, since entities,
which actively participate in the signaling protocol, must be able
to 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
skipping to change at page 22, line 22 skipping to change at page 22, line 23
(Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University
of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
actively contributed new text to 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. thanks Alison Mankin for the thorough AD review and thanks to Harald
Tveit Alvestrand and Steve Bellovin for the IESG review comments.
9 Author's Addresses 9 Author's Addresses
Marcus Brunner (Editor) Marcus Brunner (Editor)
NEC Europe Ltd. NEC Europe Ltd.
Network Laboratories Network Laboratories
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
D-69115 Heidelberg D-69115 Heidelberg
Germany Germany
E-Mail: brunner@ccrle.nec.de E-Mail: brunner@ccrle.nec.de
skipping to change at page 29, line 53 skipping to change at page 29, line 55
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 10.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 s together with potential networks in order to setup and change reservations together with
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 s might be different (long living s of
aggregates, less often re-negotiation). 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
skipping to change at page 35, line 29 skipping to change at page 35, line 29
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 Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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