One document matched: draft-westberg-nsis-rsvp-as-ntlp-01.txt
Differences from draft-westberg-nsis-rsvp-as-ntlp-00.txt
Internet Draft RSVPv1 as NTLP March 2003
Internet Engineering Task Force L. Westberg
INTERNET-DRAFT G. Karagiannis
Expires September 2003 V. Rexhepi
Ericsson
March 2003
Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions
for modifications on RFC2205
draft-westberg-nsis-rsvp-as-ntlp-01.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Westberg, et al. Expires September 2003 [Page 1]
Internet Draft RSVPv1 as NTLP March 2003
Abstract
The Resource ReSerVation Protocol (RSVPv1) has been on the standards
track within the IETF for a number of years. During that time, the
level of vendor support and deployment has been relatively slow,
despite the desire of many to deploy technology to deliver services
with different levels of quality of service (QoS) to their customers.
The reasons for this are arguably well-understood and documented and
are not the focus of this memo. This memo is proposing a (NSIS
Transport Layer Protocol) NTLP that is a modified version of RSVPv1
specified in RFC2205. Furthermore, it provides design guidelines and
specifications for the development of the NLTP that is based on a
modified version of RSVPv1.
Westberg, et al. Expires September 2003 [Page 2]
Internet Draft RSVPv1 as NTLP March 2003
Table of Contents
1 Introduction ................................................. 4
1.1 Motivation of using RSVPv1 as NTLP ........................ 4
1.2 Definitions/Terminology .................................... 5
2 NTLP concept and features .................................... 8
2.1 NTLP features .............................................. 8
2.2 NTLP Message Formats ....................................... 9
2.2.1 Common Header ............................................ 10
2.2.2 Transport layer object formats ........................... 12
2.3 NTLP concept ............................................... 14
3 Suggestions for modifications on RFC2205 ..................... 16
4 References ................................................... 18
5 Authors' Addresses ........................................... 19
Westberg, et al. Expires September 2003 [Page 3]
Internet Draft RSVPv1 as NTLP March 2003
1. Introduction
A number of different QoS solutions have been developed by the IETF,
amongst them IntServ and its signalling protocol, RSVPv1, defined in
[RFC2205]. RSVPv1 [RFC2205] is a resource reservation signalling
protocol that was designed to be applied in an end-to-end
communication path. It can be used by an application to make its QoS
requirements known and reserve resources in all the network nodes in
the path.
The NSIS WG uses the two-level architecture for Internet Signaling
proposed in [BrLi01]:
(1) a common lower level that performs transport-layer functions.
This common lower level is denoted in [Hanco2] as
NSIS Transport Layer Protocol (NTLP) that is a placeholder
name for the NSIS protocol component that will support lower
layer (signaling application independent) functions.
(2) a set of upper-level signaling functions that are specific
to particular signaling applications. These upper-level
signaling tasks and functions are accomplished by a set of
signaling layer protocols denoted in [Hanc02] as NSIS Signaling
Layer Protocol (NSLP).
This memo outlines the main concept that is used by the proposed NTLP
and provides guidelines and specifications for the modifications that
have to be done in RFC2205 [RFC2205], such that RSVPv1 can be applied
as NTLP.
1.1. Motivation of using RSVPv1 as NTLP
A great deal of effort was put into the specification and design of
the RSVPv1 [RFC2205] protocol. RSVPv1 is well-designed for the
applications for which it was intended and worked hard to provide a
modular protocol within the constraints of its intended use.
The main transport-layer features supported by RSVPv1 [RFC2205], such
as support of unicast path-coupled signaling and soft state support
have been proven in practice of being lightweight and robust.
However, the multicast support introduces a level of complexity into
the RSVPv1 protocol that is not needed in support of unicast
applications. For example, RSVPv1's state maintenance is complex as
Westberg, et al. Expires September 2003 [Page 4]
Internet Draft RSVPv1 as NTLP March 2003
it needs to support dynamic membership changes in the multicast
groups, such as reservation state merging and maintenance.
Our working assumption is that RSVPv1 should be optimized for unicast
rather than multicast and that relaxing this design constraint will
in turn greatly simplify the protocol.
Using RSVPv1 as NTLP will eliminate the need of reinventing solutions
for transport-layer features. Furthermore, this will shorten the time
needed to standardize NTLP by reusing the current RSVP design
experience and RSVP protocol specification. Moreover, after minor
modifications, existing RSVPv1 [RFC2205] implementations can be
reused and used as NTLP, decreasing the deployment costs.
Additional transport-layer features can be introduced in a modular
way, either by adding them one by one as optional features into the
NTLP specifications and implementations or using an existing protocol
below NTLP that could provide these additional features.
1.2. Definitions/Terminology
Interdomain traffic:
Traffic that passes from one NSIS domain to
another ([identical to [Hanc02]).
Intra-domain NSIS signaling is where the NSIS signaling messages are
originated, processed and terminated within the same NSIS domain.
NSIS Domain (ND) (identical to [Hanc02]):
Administrative domain where an NSIS protocol
signals for a resource or set of resources.
NSIS Entity (NE) (identical to [Hanc02]):
the function within a node which implements an
NSIS protocol. In the case of path-coupled signaling, the
NE will always be on the data path.
Westberg, et al. Expires September 2003 [Page 5]
Internet Draft RSVPv1 as NTLP March 2003
NSIS Forwarder (NF) (identical to [Hanc02]):
NSIS Entity between a NI and NR which may
interact with local resource management function (RMF). It also
propagates NSIS signaling further through the network.
NF Edge nodes:
NF Nodes that are located at the boundary of an administrative
domain, e.g., Diffserv. This node is a NTLP stateful node.
NF Interior node:
All the nodes that are part of an administrative domain, e.g.,
Diffserv, and are not NF edge nodes. An interior node can be
either a NTLP stateful node or a NTLP stateless node.
NF Ingress node:
An NF edge node that handles the traffic as it enters the
domain. This node is a NTLP stateful node.
NF Egress node:
An NF edge node that handles the traffic as it leaves the
domain. This node is a NTLP stateful node.
NSIS Initiator (NI) (identical to [Hanc02]):
NSIS Entity that initiates NSIS signaling for a
network resource.
NSIS Responder (NR) (identical to [Hanc02]):
NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well.
NSIS Signaling Layer Protocol (NSLP) (identical to [Hanc02]):
generic term for an NSIS protocol component that supports a specific
signaling application.
NSIS Transport Layer Protocol (NTLP) (identical to [Hanc02]):
Westberg, et al. Expires September 2003 [Page 6]
Internet Draft RSVPv1 as NTLP March 2003
placeholder name for the NSIS protocol component that will support
lower layer (signaling application independent) functions.
NTLP aware node:
a node that implements and supports the NTLP protocol.
NTLP stateful node:
a NTLP aware node that maintains a NTLP transport layer state.
NTLP stateless node:
a NTLP aware node that does not maintain a NTLP transport layer
state.
NE NTLP stateful
NE entity that is NTLP stateful.
NE NTLP stateless
NE entity that is NTLP stateless.
NF NTLP stateful
NF entity that is NTLP stateful.
NF NTLP stateless
NF entity that is NTLP stateless.
Resource Management Function (RMF) (identical to [Hanc02]):
an abstract concept,
representing the management of resources in a domain or a node.
End Host:
QoS-aware end terminal, either fixed or mobile, i.e. running
QoS-aware applications. This node is a NTLP stateful node and it
Westberg, et al. Expires September 2003 [Page 7]
Internet Draft RSVPv1 as NTLP March 2003
can be considered as a NI or a NR.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. NTLP concept and features
As mentioned in Section 1 of this memo the NTLP performs transport-
layer functions that are signaling application independent.
2.1. NTLP features
The NTLP provides the following subset of transport layer functions:
* Support of Path-Coupled (Path-Directed) Signaling. The NTLP
signaling messages are routed on the same path as the path
followed by the data path. NTLP is not itself a routing protocol
and it should be designed to operate with current and future
routing protocols. Similar to RSVPv1 [RFC2205], a NTLP process,
consults the local routing database(s) to obtain routes.
* Soft state support: This feature is similar to the soft state feature
supported by RSVPv1 [RFC2205] and ensures that a state will be removed
if it is not periodically refreshed or explicitly removed. This state is
mainly used as a path state, where it maintains path-coupled routing
information. The NTLP soft state, similar to RSVPv1, is created and
periodically refreshed by Path and Resv messages. This state, similar
to RSVPv1, is deleted either if no matching refresh messages arrive
before the expiration of a "cleanup timeout" interval, or may also be
deleted by an explicit "teardown" message, i.e., PathTear or ResvTear.
At the expiration of each "refresh timeout" period and after a state
change, NTLP scans its state to build and forward Path and Resv refresh
messages to succeeding hops.
The state is globally and unique identified by a transport state
identifier that is associated to a data flow and has to remain unchanged
for the complete duration of the data flow. Moreover, for the duration of a
data flow, the transport state identifier remains the same while the
Westberg, et al. Expires September 2003 [Page 8]
Internet Draft RSVPv1 as NTLP March 2003
flow ID information associated with the same data flow might change. For
example, in a mobile IP scenario, during handover the IP address of a
mobile node might change, causing a change in the flow ID of an ongoing
data flow. However, the transport state identifier associated with that data
flow should not change. The RSVPv1 "Session" object can be applied as
NTLP transport state ID.
* Adaptation to load sharing. Load sharing allows NF interior
nodes to take advantage of multiple routes to the same
destination by sending via some or all of these available
routes. The NTLP protocol level has to adapt to load sharing once
it is used.
* The NTLP signaling protocol is able to exchange local information
between NSIS Forwarders located within one single administrative
domain.
* In case of unexpected situations, e.g., errors, any NSIS Forwarder
is able to asynchronously generate a signaling message.
* NTLP transports application layer (NSLP) "objects" that are
opaque to NTLP.
* NTLP provides transparent operation through routers that do not
support it.
* NTLP supports both IPv4 and IPv6.
2.2. NTLP Message Formats
NTLP uses the existing RSVPv1 signaling messages as NTLP transport
protocol messages. However, ResvConf is not anymore used, since the
confirmation of a reservation is considered to be an application
layer related feature. The NTLP message types are: Path, Resv,
PathErr, ResvErr, ResvTear. The main difference is related to the
objects that will be carried by these messages, where the number of
mandatory objects is reduced substantially.
The NTLP message, see Figure 1, consists of a common header, followed
by a body consisting of a number of variable-length, typed transport
layer "objects". The application layer (NSLP) "objects" are placed
always after the transport layer "objects". Note that the application
Westberg, et al. Expires September 2003 [Page 9]
Internet Draft RSVPv1 as NTLP March 2003
layer (NSLP) "objects" are opaque and transparent to NTLP. A router
implementation should create and read messages with the objects in
the order shown in [RFC2205]. However, note that only a subset of the
objects specified in [RFC2205] are needed in NTLP.
0 1 2 3
+-------------+-------------+-------------+-------------+
| |
+ Common Header +
| |
+-------------+-------------+-------------+-------------+
| |
// (Transport layer objects content) //
| |
+-------------+-------------+-------------+-------------+
| |
// (Application layer (NSLP) objects content) //
| |
+-------------+-------------+-------------+-------------+
Figure 1: NTLP message format
2.2.1. Common Header
The common header, excluding the ResvConf message, is identical to
the RSVPv1 Common header specified in [RFC2205].
Westberg, et al. Expires September 2003 [Page 10]
Internet Draft RSVPv1 as NTLP March 2003
0 1 2 3
+-------------+-------------+-------------+-------------+
| Vers | Flags| Msg Type | RSVP Checksum |
+-------------+-------------+-------------+-------------+
| Send_TTL | (Reserved) | RSVP Length |
+-------------+-------------+-------------+-------------+
The fields in the common header are as follows:
Vers: 4 bits
Protocol version number. This is version 1.
Flags: 4 bits
0x01-0x08: Reserved
No flag bits are defined yet.
Msg Type: 8 bits
1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
RSVP Checksum: 16 bits
The one's complement of the one's complement sum of the
message, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value
means that no checksum was transmitted.
Send_TTL: 8 bits
Westberg, et al. Expires September 2003 [Page 11]
Internet Draft RSVPv1 as NTLP March 2003
The IP TTL value with which the message was sent. See
Section 3.8.
RSVP Length: 16 bits
The total length of this RSVP message in bytes, including
the common header and the variable-length objects that
follow.
2.2.2. Transport layer object formats
Similar to [RFC2205], every object consists of one or more 32-bit
words with a one-word header, with the following format:
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| |
// (Transport layer object content) //
| |
+-------------+-------------+-------------+-------------+
An object header has the following fields:
Length
A 16-bit field containing the total object length in
bytes. Must always be a multiple of 4, and at least 4.
Class-Num
Identifies the object class (see [RFC2205]); An NTLP
implementation must recognize the following classes:
NULL (as in [RFC2205])
A NULL object has a Class-Num of zero, and its C-Type
is ignored. Its length must be at least 4, but can
be any multiple of 4. A NULL object may appear
anywhere in a sequence of objects, and its contents
will be ignored by the receiver.
SESSION (as in [RFC2205])
Westberg, et al. Expires September 2003 [Page 12]
Internet Draft RSVPv1 as NTLP March 2003
Contains the IP destination address (DestAddress),
the IP protocol id, and some form of generalized
destination port, to define a specific session for
the other objects that follow. Required in every
NTLP message. The "Session" object can be
applied as NTLP transport state ID.
RSVP_HOP (as in [RFC2205])
Carries the IP address of the NTLP aware node that
sent this message and a logical outgoing interface
handle (LIH). This document refers
to a RSVP_HOP object as a PHOP ("previous hop")
object for downstream messages or as a NHOP (" next
hop") object for upstream messages.
TIME_VALUES (as in [RFC2205])
Contains the value for the refresh period R used by
the creator of the message;
Required in every Path and Resv message.
ERROR_SPEC (as in [RFC2205])
Specifies an error in a PathErr, ResvErr, or a
confirmation in a ResvConf message.
INTEGRITY (as in [RFC2205])
Carries cryptographic data to authenticate the
originating node and to verify the contents of this
NTLP message. The use of the INTEGRITY object is
described in [RFC2747].
C-Type
Object type, unique within Class-Num. Values are defined
in [RFC2205].
Westberg, et al. Expires September 2003 [Page 13]
Internet Draft RSVPv1 as NTLP March 2003
2.3. NTLP concept
The NTLP protocol can be used for End-to-End, Edge-to-Edge, and End-
to-Edge scenarios. In the End-to-End scenario both NSIS end nodes
are functioning as NSIS Initiators (NI) and NSIS Responders (NR). In
the Edge-to-Edge scenario, both NSIS edge nodes are functioning as
NI, NR and NSIS Forwarders (NF). In the End-to-Edge scenario the
NSIS end host is functioning as a NI or NR and the edge node is
functioning as a NI, NR and NF.
The NSIS framework shown in Figure 2 and Figure 3 is separated in two
different levels. The lowest hierarchical level represents the NTLP
level protocol and the higher hierarchical level represents the NSLP.
Note that the NF nodes are usually considered to be NTLP stateful
nodes. This holds also for the NF nodes used at the boundary of a
domain, i.e., the NF edge nodes. However, the NF interior nodes of a
domain can be either NTLP stateful nodes (see Figure 2) or, when
processing optimisation is required, the NF interior nodes can be
NTLP stateless nodes (see Figure 3). The NF NTLP stateful nodes are
NF NTLP aware nodes that maintain a NTLP state by using the NTLP soft
state principle and are able to process and modify the application
level information (NSLP) that is transported by the NTLP protocol.
The NF NTLP stateless nodes are NF NTLP aware nodes that do not
maintain a NTLP state, but they are able to process and modify the
application level information (NSLP) that is transported by the NTLP
protocol. The interface between NTLP and NSLP can be based on an
Application Program Interface (API) and its specification is ouf of
the scope of this memo.
Westberg, et al. Expires September 2003 [Page 14]
Internet Draft RSVPv1 as NTLP March 2003
|------| |-------| |-------| |-------| |-------| |------|
| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |
| | | | | | | | | | | |
|------| |-------| |-------| |-------| |-------| |------|---
| | | | | | | | | | | | ^
| | | | | | | | | | | | |
-------------------------------------------------------------------API
| | | | | | | | | | | | |
| | | | | | | | | | | | v
|------| |-------| |-------| |-------| |-------| |------|---
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |
|st.ful| |st.ful | |st.ful | |st.ful | |st.full| |st.ful|
|------| |-------| |-------| |-------| |-------| |------|
NI NF NF NF NF NR
(edge) (interior) (interior) (edge)
NTLP st.ful : NTLP stateful
Figure 2: NTLP/NSLP framework with stateful NF(interior) nodes
Westberg, et al. Expires September 2003 [Page 15]
Internet Draft RSVPv1 as NTLP March 2003
|------| |-------| |-------| |-------| |-------| |------|
| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |
| | | | | | | | | | | |
|------| |-------| |-------| |-------| |-------| |------|---
| | | | | | | | | | | | ^
| | | | | | | | | | | | |
-------------------------------------------------------------------API
| | | | | | | | | | | | |
| | | | | | | | | | | | v
|------| |-------| |-------| |-------| |-------| |------|---
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.full| |st.ful|
|------| |-------| |-------| |-------| |-------| |------|
NI NF NF NF NF NR
(edge) (interior) (interior) (edge)
NTLP st.ful : NTLP stateful
NTLP st.less : NTLP stateless
Figure 3: NTLP/NSLP framework with stateless NF(interior) nodes
3. Suggestions for modifications on RFC2205
Based on the introduced features and concept presented in Section 2,
we've gone through the RFC2205 to find out how much of the RSVPv1
specification can be reused in changing RSVPv1 into an NTLP. We've
seen that a lot of work and text available in RFC2205 can be re-used
in specifying a modified version of RSVPv1 that can be used as NTLP.
A list with such changes on RFC2205 is given below.
RFC2205 table of contents:
* Section 1 of RFC2205: Introduction - needs to be re-written
1.1 Data Flows
1.2 Reservation Model - needs to be re-written
to introduce the used transport model
1.3 Reservation Styles - is not needed anymore as this is
Signaling Application specific
1.4 Examples of Styles - is not needed anymore as this is
Signaling Application specific
* Section 2 of RFC2205: RSVP Protocol Mechanisms
2.1 RSVP Messages - minor changes are needed to emphasise
that these messages are mainly used for
Westberg, et al. Expires September 2003 [Page 16]
Internet Draft RSVPv1 as NTLP March 2003
transport layer functionality.
2.2 Merging Flowspecs - is not needed anymore as this is
Signaling Application specific
2.3 Soft State - needs to be changed such that it explains
transport state management functionality,
see Section 2 of this memo.
2.4 Teardown - needs to be changed such that it explains
transport state management functionality
2.5 Errors - minor changes are needed to emphasize the
transport layer functionality
2.6 Confirmation - is not needed anymore as this is
Signaling Application specific
2.7 Policy Control - is not needed any more as this is
Signaling Application specific
2.8 Security - minor changes are needed to emphasize the
transport layer functionality
2.9 Non-RSVP Clouds - may remain the same
2.10 Host model- we can reuse it, but we'll need to update
it to emphaise the transport layer
functionality
* Section 3 of RFC2205: RSVP Functional Specification
3.1 RSVP Message Formats - remains basically the same
apart from the objects, i.e. the mentioned objects in
Section 2 of this memo remain while the rest of the
objects will be removed completely.
.
.
3.2 Port Usage - remains the same
3.3 Sending RSVP Messages - remains the same apart from the
multicast part which we'll need to remove
3.4 Avoiding RSVP Message Loops - remains the same. Here there
is a paragraph that explains what to do when WF is used,
which it could be removed.
3.5 Blockade State - probably it could be removed, since the
blockade state can be considered as Signaling
Application specific
3.6 Local Repair - minor changes are needed to emphasize the
transport layer functionality
3.7 Time Parameters - minor changes are needed to emphasize the
transport state management and refresh
mechanisms.
3.8 Traffic Policing and Non-Integrated Service Hops - is not
Westberg, et al. Expires September 2003 [Page 17]
Internet Draft RSVPv1 as NTLP March 2003
needed as it is Signaling Application
specific, i.e., Intserv specific
3.9 Multihomed Hosts - may be reused
3.10 Future Compatibility remains the same
3.11 RSVP Interfaces - it will either be completely removed
or it will be changed to define new API interfaces
to the signaling application layer (NSLP).
* Section 4 of RFC2205: Acknowledgements
needs of course to be re-written
* APPENDIX A. Object Definitions - needs to be changed, according
to the details provided in Section 2 of this memo.
* APPENDIX B. Error Codes and Values - most error codes and values
will remain the same. However, new error codes and values
might be defined.
* APPENDIX C. UDP Encapsulation - remains the same
* APPENDIX D. Glossary - needs to be updated accordingly with the
changes in the document
* REFERENCES - need to be updated accordingly
4. References
[BrLi01] Braden, R., Lindell, B., "A Two-Level Architecture for
Internet Signaling", Internet Draft (work in progress),
2001.
[Hanc02] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.,
Van den Bosch, S., "Next Steps in Signaling: Framework",
Internet Draft, 2002, Work in progress.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A.,
Jamin, S., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", IETF RFC
2205, 1997.
[RFC2747] F. Baker, B. Lindell, M.Talwar. "RSVP Cryptographic
Authentication", IETF RFC, January 2000.
Westberg, et al. Expires September 2003 [Page 18]
Internet Draft RSVPv1 as NTLP March 2003
5. Authors' Addresses
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@era.ericsson.se
Georgios Karagiannis
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645 7500 AP Enschede
The Netherlands
EMail: Georgios.Karagiannis@eln.ericsson.se
Vlora Rexhepi
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645 7500 AP Enschede
The Netherlands
EMail: Vlora.Rexhepi@eln.ericsson.se
Westberg, et al. Expires September 2003 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:38 |