Internet DRAFT - draft-choi-ipv6-signaling-req-ntlp
draft-choi-ipv6-signaling-req-ntlp
Internet Draft Jun Kyun Choi
Document: draft-choi-ipv6-signaling-req-ntlp-00.txt Hyun Hye Lee
Expiration Date: December 2003 Gyu Myoung Lee
ICU
Hyoung Jun Kim
Ki Shik Park
ETRI
Tae-Gon Noh
June-Koo Rhee
Samsung AIT
July 2003
Requirements for IPv6 Signaling as NTLP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026.
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 obsolete 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.
Abstract
In this draft, we present the features of IPv6 protocol related to
NSIS Transport Layer Protocol (NTLP) and requirements for IPv6
signaling as NTLP in different Internet transport infrastructure,
such as SDH/SONET switch, Optical cross-connect (OXC), ATM switch,
Ethernet switch, wireless system, and router. In this framework, user
data is transported via nodes in the data plane and signaling
messages are routed to NEs in the control plane. We propose the new
protocol, Internet Signaling Message Protocol (ISMP) for carrying
signaling messages. And other delivering methods of signaling
messages in IPv6 network are also presented in appendix.
Choi, et. al. [Page 1]
Requirements for IPv6 Signaling as NTLP July 2003
Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction.....................................................3
1.1. Existing QoS Signaling Protocols and NSIS Activities...........3
1.2. Motivation of IPv6 Signaling as NTLP...........................4
2. Overview of IPv6 Signaling Concept and Features..................4
2.1. Signaling Framework............................................4
2.2. The Features of IPv6 Protocol related to NTLP..................5
3. Requirements for IPv6 Signaling as NTLP..........................6
3.1. Resource Reservation...........................................6
3.2. Flow Label Distribution........................................6
3.3. Backward Compatibility.........................................6
3.4. Easy to implement..............................................6
3.5. Scalability....................................................7
3.6. Mobility Support...............................................7
3.7. Signaling Interworking.........................................7
3.7.1. Signaling Interworking between IPv6 and IPv4.................7
3.7.2. Signaling Interworking between IPv6 and Existing Telco Network
....................................................................9
3.7.3. Support of Domain Service Model on Optical Transport Network10
4. IPv6 Next Header for Signaling..................................11
5. IANA Considerations.............................................12
6. Security Considerations.........................................12
Appendix. The delivering Methods for Signaling Messages in IPv6
Network............................................................13
7. References......................................................15
8. Author's Addresses..............................................17
Choi, et. al. [Page 2]
Requirements for IPv6 Signaling as NTLP July 2003
1. Introduction
There is the transition of the Internet from IPv4 to IPv6. IPv6 is
designed to run well on high performance networks (e.g., Gigabit
Ethernet, OXC, ATM, etc.) and at the same time still be efficient for
low bandwidth networks (e.g., wireless network). In addition, it
provides a platform for new Internet functionality that will be
required in the near future.
The architecture described in this draft clearly separates the
control plane and the data plane. In addition, control plane is made
of two signaling protocol layers: NSIS Transport Layer Protocol
(NTLP) and NSIS Signaling Layer Protocol (NSLP) in [NSISFW]. User
data is transported via nodes in the data plane and signaling
messages are routed to NEs in the control plane. This path-decoupled
signaling take advantage of reusing existing transport devices whose
data plan cannot recognize the IP header and having flexibility in NE
deployment.
Actually, IPv6 has many native features to support QoS and other
capabilities for the emerged network, such as Hop-by-Hop Option
header, Routing Option header, and Destination Option header as
described in [RFC1883]. We will describe about that in section 2.2.
By utilizing this IPv6 features, we can assist the existing signaling
protocols without modifying themselves and it can provide additional
features to NTLP. On the other hand, one who doesn't care of the
modification of the existing signaling protocols may modify slightly
the existing signaling mechanisms to adopt IPv6 signaling as NTLP. We
present requirements for IPv6 signaling as NTLP in section 3.
Also we will propose the methods those modify existing signaling
protocol specifications to make use of the power of IPv6 function to
the signaling mechanisms in section 4. And other delivering methods
of signaling messages in IPv6 network are also presented in appendix.
1.1. Existing QoS Signaling Protocols and NSIS Activities
A number of different QoS mechanisms have been developed by the IETF.
Usually the QoS mechanisms are supported in the IP layer or the
Transport layer (e.g., TCP or UDP). We can regard following QoS
signaling protocols.
o RSVP-TE(including RSVP-TE extension for GMPLS [RFC3473])
RSVP-TE [RFC3209] specifies the extension to RSVP for establishing
traffic engineered path. Both RSVP [RFC2210] and RSVP-TE are
implemented on the IP layer. RSVP is defined to support QoS in IP
network with fine granularity, but this leads the scalability
problems. RSVP-TE has some additional concepts, like label
distribution, aggregated flow, and explicit route.
Choi, et. al. [Page 3]
Requirements for IPv6 Signaling as NTLP July 2003
o CR-LDP(including CR-LDP extension for GMPLS [RFC3472])
CR-LDP [RFC3212], from LDP, use the TCP(and UDP) layer instead of IP
layer in RSVP-TE. So this signaling protocol uses the features of TCP
protocol.
The NSIS Working Group focuses on providing end-to-end signaling
across different network environment and develops the requirements,
architecture and protocols for the next IETF steps on signaling. They
defines requirements for signaling in [NSISREQ], analyzes existing
protocols for signaling the QoS requirements of flows to nodes in an
IP network in [NSISANALYSIS], and provides a model for the network
entities that take part in signaling in [NSISFW].
1.2. Motivation of IPv6 Signaling as NTLP
Carriers are currently migrating to a consolidated single network
based on IP technology called the Next-Generation Network (NGN) and
so future transport networks is expected to be made of different
transport elements such as SDH/SONET switch, Ethernet switch, ATM
switch, OXC, wireless system, router, etc. NGN clearly separate
control functions from transport functions, both service control
functions and network resource control functions.
And the current Internet is transiting from IPv4 to IPv6. We cannot
predict the deployment step of IPv6 in real environment. But we can
assume that the mobile access network is the major application of
IPv6. This is mainly due to the large address space of IPv6. Also we
can predict that the large percentile of packets in that network will
be carried real time traffic such as voice or video. It is worth to
lay emphasis on these applications will heavily depend on the QoS
mechanism in IPv6 networks. But, existing signaling protocols concern
only on delivery signaling message over IPv4 network as we see
section 1.1.
In signaling point of view, IPv6 protocol has many features related
to QoS and other capabilities. By utilizing IPv6 features, such as
ease of defining explicit route, flow labeling capability and
improved support for extensions and options like Hop-by-Hop Option
header or Destination Option header, we can improve the efficiency of
IPv6 networks and we can enjoy that without modifying the existing
signaling protocols.
2. Overview of IPv6 Signaling Concept and Features
2.1. Signaling Framework
Figure 1 shows a diagram of signaling framework for future Internet
based on different transport network. The architecture clearly
Choi, et. al. [Page 4]
Requirements for IPv6 Signaling as NTLP July 2003
separates the control plane and the data plane. In addition, control
plane is made of two signaling protocol layers: NSIS Transport Layer
Protocol (NTLP) and NSIS Signaling Layer Protocol (NSLP) in [NSISFW].
Data flow messages are transported from sender to receiver via node
N1, N2 and N3 in the data plane and signaling messages are routed to
NEs in the control plane. Node in data plane can be a different
transport device such as SDH/SONET switch, Optical cross-connect
(OXC), ATM switch, Ethernet switch, wireless system, router, etc.
This path-decoupled signaling take advantage of reusing existing
transport devices whose data plan cannot recognize the IP header and
having flexibility in NE deployment.
+--------+ +--------+ +--------+ +--------+ +--------+
| NE | | NE | | NE | | NE | | NE |
| +----+ | | +----+ | | +----+ | | +----+ | | +----+ |
| |NSLP| | | |NSLP| | | |NSLP| | | |NSLP| | | |NSLP| |
| +----+ | | +----+ | | +----+ | | +----+ | | +----+ |
| || |====| || |====| || |====| || |====| || |
| +----+ | | +----+ | | +----+ | | +----+ | | +----+ |
| |NTLP| | | |NTLP| | | |NTLP| | | |NTLP| | | |NTLP| |
| +----+ | | +----+ | | +----+ | | +----+ | | +----+ |
+--------+ +--------+ +--------+ +--------+ +--------+
Control plane
---------------------------------------------------------------------
Data plane
+--------+ +--------+ +--------+ +--------+ +-------- +
| Sender |--->| N1 |--->| N2 |--->| N3 |--->| Receiver|
| App | | | | | | | | App |
+--------+ +--------+ +--------+ +--------+ +---------+
Appp = Application N1, N2, N3 = node
==== = Signaling Messages ---> = Data flow Messages
Figure 1. Signaling framework
2.2. The Features of IPv6 Protocol related to NTLP
To validate the further discussion, we must describe the native
features of IPv6 protocol related to NTLP.
o Priority Flow Control
Each node has many flows with different priority of various data
rates and QoS requirements. These flows are classified and scheduled
Choi, et. al. [Page 5]
Requirements for IPv6 Signaling as NTLP July 2003
with the capability of making intelligent decisions on how resource
allocation SHOULD be controlled. The Priority filed in IPv6 header
[RFC1883] enables a source to identify the desired delivery priority
of its packets, relative to other packets form the same source.
o Explicit Route
In IPv6 specification [RFC1883], there is a route extension header to
use explicit route. Explicit route is important for traffic
engineering in IPv6 networks. There is already ROUTE object in RSVP-
TE specification [RFC3209]. In the case of CR-LDP [RFC3212], some
TLVs are defined to be used for this purpose. We discuss the explicit
route setup for interworking with MPLS signaling in IPv6 network.
(See section 4.2)
o Flow Identification.
In IPv6 flow label specification [FLOWLABEL], flow identification
includes the 3-tuple of the Flow Label and the Source and Destination
Address fields. Flow state is created and stored by the NEs and
packet classification is done by the node on data plane.
3. Requirements for IPv6 Signaling as NTLP
This section defines requirements for IPv6 signaling as NTLP.
3.1. Resource Reservation
The key role of signaling protocol is to allocate and reserve the
network resource for the purpose of meeting end-to-end QoS
requirements along the entire path. The IPv6 signaling protocol MUST
be able to deal with such resource allocation request.
3.2. Flow Label Distribution
To make use of flow label field of IPv6 basic header and identify the
flow label between the nodes on specific data path, label-binding
information SHOULD be delivered between the related nodes. The
related nodes are on the specific path of the flow. Label value is
only meaningful between a pair of nodes. And the label value is
predetermined before forwarding data packet along the path.
3.3. Backward Compatibility
The existing signaling protocols such as RSVP, RSVP-TE, CR-LDP and so
on are implemented in IPv4 network. These signaling protocols MUST be
operated in IPv6 network. Therefore, they MUST support backward
compatibility for operating both IPv6 and IPv4.
3.4. Easy to implement
Choi, et. al. [Page 6]
Requirements for IPv6 Signaling as NTLP July 2003
There are two aspects related with this issue. First, we can consider
the compatibility of the new signaling with existing signaling. So
the implementation can be done with minimum modification of previous
architecture and components. Second we can omit some functions of
previous signaling so that we just make a light-weight signaling
mechanism. We are still studying about this carefully because it
makes some effects with other various factors such like the
capabilities of this new signaling and the signaling translation
between two heterogeneous AS's. We can think above two factors
simultaneously and SHOULD make some trade-off.
3.5. Scalability
The performance of the signaling protocol SHOULD not largely depend
on the scale of the network to which IPv6 is applied (e.g. the number
of nodes, the number of physical links etc). The signaling function
SHOULD keep constant performance as much as possible regardless of
network size. Aggregating flows can reduce resource allocation and
runtime management overhead.
3.6. Mobility Support
To provide the QoS in mobile environment, we SHOLD consider the
mobility of nodes and dynamic behavior of related flows. In signaling,
we are concerning two problems. First the flow management can be
considered with per aggregated flow or per flow. In some point,
snapshot of network can be described with many aggregated flows and
related QoS management. But as time goes, some flow of mobile node
departs one aggregated flow and join the other aggregated flow.
Second the support of micro mobility issues. To make use of old flow
related resources as much as possible, we should define Nearest
Common Router (NCR) and provide the finding mechanism. This work is
under working. We just consider the need of modification or
adaptation of that mechanism in our work.
3.7. Signaling Interworking
Most of the signaling protocols are based on the underlying network
infrastructure, i.e. IP networks, but they don't depend on the minor
version of the network. For example, one signaling protocol designed
for the IPv4 network can be used in IPv6 network without modifying
the specification of the signaling mechanism. Rather than to do like
that, the signaling protocol adopt itself to the different version of
network implementation by defining option fields like IP version
information field and related information like IPv4 addresses (32
bits) or IPv6 addresses (128 bits). Therefore, Signaling in IPv6
network MUST consider the interworking with IPv4 network and existing
wireline/wireless telco network.
3.7.1. Signaling Interworking between IPv6 and IPv4
Choi, et. al. [Page 7]
Requirements for IPv6 Signaling as NTLP July 2003
To be gradually deployed, we can consider the situation of mixed
nodes that some implement the IPv6 signaling and others implement the
IPv4 signaling. Deployment point of view, we consider three stages of
evolution scenarios.
- first stage (stage 1): IPv4 ocean and IPv6 island
- second stage (stage 2): IPv6 ocean and IPv4 island
- third stage (stage 3): IPv6 ocean and IPv6 island
In first stage shown in Figure 2, MPLS-based core network (e.g., IPv4
ocean) and IPv6 access network (e.g., IPv6 island) is deployed. In
this environment, core signaling such as RSVP-TE and CR-LDP is used
in IPv4 ocean and access signaling such as RSVP and RSVP-TE is used
in IPv6 island. To support end-to-end QoS signaling, these protocols
SHOUD perform the mapping of IPv6 with IPv4. Flow label information
of IPv6 header is translated to FEC(Forwarding Equivalent Class)
[RFC3031] information of MPLS. For this reason, signaling
interworking function is needed. Using this QoS signaling, flow
information is transmitted unchanged from source to destination and
the required resource is reserved and end to end path is established.
+-------------+ +---------------+ +-------------+
| IPv6 island |-------| IPv4 ocean |-------| IPv6 island |
| |-------| (MPLS) |-------| |
+-------------+ +---------------+ +-------------+
Flow Label -- mapping -- FEC -- mapping -- Flow Label
|<----------->| |<------------->| |<----------->|
RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE
(Access signaling) (Core signaling) (Access signaling)
|<--------------------------------------------------------->|
end-to-end QoS signaling
Figure 2. Signaling mapping (stage 1)
In second stage shown in Figure 3, IPv6 network will dominate over
IP4 network. This network is composed of IPv6-based core network
(e.g., IPv6 ocean) and IPv4-based access network (e.g., IPv4 island).
The existing IPv4 network is operated in MPLS. In this environment,
core signaling such as RSVP-TE and CR-LDP is used in IPv6 ocean and
access signaling such as RSVP and RSVP-TE is used in IPv4 island. FEC
information of IPv4 is translated to flow label information of IPv6.
+-------------+ +---------------+ +-------------+
| IPv4 island |-------| IPv6 ocean |-------| IPv4 island |
| (MPLS) |-------| |-------| (MPLS) |
Choi, et. al. [Page 8]
Requirements for IPv6 Signaling as NTLP July 2003
+-------------+ +---------------+ +-------------+
FEC -- mapping -- Flow Label -- mapping -- FEC
|<----------->| |<------------->| |<----------->|
RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE
(Access signaling) (Core signaling) (Access signaling)
|<--------------------------------------------------------->|
end-to-end QoS signaling
Figure 3. Signaling mapping (stage 2)
In third stage shown in Figure 4, IPv6 protocol is implemented both
core network (e.g., IPv6 ocean) and access network (e.g., IPv6
island). Signaling protocol like RSVP-TE MAY be used without
signaling translation.
+-------------+ +---------------+ +-------------+
| IPv6 island |-------| IPv6 ocean |-------| IPv6 island |
+-------------+ +---------------+ +-------------+
Flow Label - mapping -- Flow Label -- mapping - Flow Label
|<----------->| |<------------->| |<----------->|
RSVP/RSVP-TE RSVP-TE/CR-LDP RSVP/RSVP-TE
(Access signaling) (Core signaling) (Access signaling)
|<--------------------------------------------------------->|
end-to-end QoS signaling
Figure 4. Signaling mapping (stage 3)
3.7.2. Signaling Interworking between IPv6 and Existing Telco Network
We SHOULD consider the signaling interworking between IPv6 and
existing Telco network. Telco network may be composed of PSTN,
cellular, IMT2000 network and so on. Using signaling, the
physical/logical circuit is established. To support end-to-end QoS
signaling, we consider two cases (see Figure 5-6). Both cases SHOUD
perform the mapping of flow label and phsyiscal/logical circuit.
+-------------+ +-----------------+ +-------------+
| IPv6 Client |------| PSTN/Cellular/ |------| IPv6 Client |
| Network |------| IMT2000-Network |------| Network |
+-------------+ +-----------------+ +-------------+
Flow label - mapping - physical/logical- mapping - Flow Label
Circuit
|<----------->| |<--------------->| |<----------->|
Choi, et. al. [Page 9]
Requirements for IPv6 Signaling as NTLP July 2003
Acess Signaling Telco Signaling Access Signaling
|<--------------------------------------------------------->|
end-to-end QoS signaling
Figure 5. Signaling mapping for Telco network (case 1)
+-------------+ +-----------------+ +-------------+
| PSTN |------| IPv6 |------| Cellular |
| ISDN |------| Ocean |------| INT-2000 |
+-------------+ +-----------------+ +-------------+
Physical/ -- mapping - Flow Label-- mapping - Physical/
Logical Circuit Logical Circuit
|<----------->| |<--------------->| |<----------->|
Telephone Signaling Core Signaling Cellular/
IMT-2000 Signaling
|<--------------------------------------------------------->|
end-to-end QoS signaling
Figure 6. Signaling mapping for Telco network (case 2)
3.7.3. Support of Domain Service Model on Optical Transport Network
IPv6 network SHOULD support the signaling interworking with optical
transport network. The optical transport network control plane reuse
IP-based protocols that are based on the signaling and routing
mechanisms developed for IP traffic engineering applications. Core
signaling such as Optical-UNI (User-Network-Interface) [UNI] and
GMPLS signaling (RSVP-TE extensions [RFC3473], CR-LDP extensions
[RFC3472]) are used in domain service model on optical transport
network (see Figure 6). To support end-to-end QoS signaling, these
protocols SHOULD perform the interworking with access signaling of
IPv6 client network. Flow label information of IPv6 is translated to
optical label information.
+-------------+ +-----------------+ +-------------+
| IPv6 Client |------|Optical Transport|------| IPv6 Client |
| Network |------| Network |------| Network |
+-------------+ +-----------------+ +-------------+
Flow label - mapping -- Optical Label -- mapping - Flow Label
|<----------->| |<--------------->| |<----------->|
Acess Signaling O-UNI, GMPLS Signaling Access Signaling
|<--------------------------------------------------------->|
end-to-end QoS signaling
Figure 7. Signaling mapping for optical network
Choi, et. al. [Page 10]
Requirements for IPv6 Signaling as NTLP July 2003
4. IPv6 Next Header for Signaling
To delivery signaling messages in IPv6 networks, we propose method
using the new Next Header value for signaling message and define this
new protocol as Internet Signaling Message Protocol (ISMP).
Message body includes signaling messages like RSVP, RSVP-TE, CR-LDP.
Every signaling message is preceded by an IPv6 header or by more IPv6
extension headers. The signaling message is identified by a Next
Header value in the immediately preceding header.
The signaling messages have the following general format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| ISMP Message Body |
+ (signaling message) +
Version 4-bit Internet Protocol version number = 6.
Traffic Class 8-bit traffic class field.
Flow Label 20-bit flow label.
Payload Length 16-bit unsigned integer. Length of the IPv6
payload, i.e., the rest of the packet
following this IPv6 header, in octets
Next Header 8-bit selector. Identifies the type of
signaling message immediately following the
Choi, et. al. [Page 11]
Requirements for IPv6 Signaling as NTLP July 2003
IPv6 header. Uses the same values as the
IPv4 Protocol field [RFC1700]
Hop Limit 8-bit unsigned integer. Decremented by 1 by
each node that forwards the packet. The
packet is discarded if Hop Limit is
decremented to zero.
Source Address 128-bit address of the originator of the
packet.
Destination Address 128-bit address of the intended recipient of
the packet (possibly not the ultimate
recipient, if a Routing header is present).
For this method, we MUST assign the new Next Header value of IPv6
header. Currently, RSVP is already assigned the value 46 decimal in
[RFC1700].
For example, if the Next Header value of IPv6 header is 46 decimal
the following ISMP message is RSVP message. The Next Header value of
other unassigned signaling messages SHOULD be assigned by IANA.
This method is very simple because of no additional extension header.
Therefore, the complexity of processing is reduced but this new
function MUST be implemented within IPv6 header.
Note: the signaling protocols, like SIP (Session Initiation
Protocol) [RFC3372], that are used for end-to-end path may use the
option TLVs to indicate the presence of the signaling information.
We already know that the real-time service cannot be served
without support of intermediate node. If some end-to-end sessions
are need to be guaranteed to their perceived QoS, the intermediate
nodes those are on the path may use the information to do
something related with QoS implicitly.
5. IANA Considerations
The value field described in Section 3 SHOULD be registered and
maintained by IANA. The New values SHOULD be to be assigned via IETF
Consensus as defined in [RFC 2434].
6. Security Considerations
This document does not have any security concerns. The security
requirements using this document are described in the referenced
documents.
Choi, et. al. [Page 12]
Requirements for IPv6 Signaling as NTLP July 2003
Appendix. The delivering Methods for Signaling Messages in IPv6 Network
In this section, we will describe methods of assisting existing
signaling protocols in IPv6 networks via using IPv6 extension headers.
1. RSVP/RSVP-TE for IPv6 (including RSVP-TE extensions for GMPLS)
IPv6 Router alert option [RFC2711] within the IPv6 Hop-by-Hop option
header has the semantic "routers should examine the datagram more
closely". Using this option, IPv6 datagram containing signaling
messages are indicated and taken actions.
The router alert option has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length = 2
The first three bits of the first byte are zero and the value 5 in
the remaining five bits is the Hop-by-Hop Option Type number.
[RFC2460] specifies the meaning of the first three bits. By
zeroing all three, this specification requires that nodes not
recognizing this option type should skip over this option and
continues processing the header and that the option must not change
en route.
There MUST only be one option of this type, regardless of value,
per Hop-by-Hop header.
Value: A 2 octets code in network byte order with the following
values
0 Datagram contains a Multicast Listener Discovery
message [RFC2710].
1 Datagram contains RSVP message.
2 Datagram contains an Active Networks message.
3-65535 Reserved to IANA for future use.
Alignment requirement: 2n+0
Values are registered and maintained by the IANA.
We suggest the new value (= 3) for RSVP-TE messages. The value 3 is
REQUIRED the approval of IETF and SHOULD be assigned by IANA. Other
signaling messages MAY be added. In this case, the value for new
signaling message SHOULD be assigned by IANA.
The described method has some advantages and disadvantages. It is not
necessary to implement the new protocol for signaling. The existing
Choi, et. al. [Page 13]
Requirements for IPv6 Signaling as NTLP July 2003
signaling message is used without change. However, all IPv6 datagram
containing a signaling message MUST contain this option within the
IPv6 Hop-by-Hop Option Header of such datagram. The additional option
header is redundant.
2. CR-LDP for IPv6 (including CR-LDP extensions for GMPLS)
In the case of RSVP-TE, if the header of a packet is indicating "This
packet carries the signaling information." then the NEs can make
different treatment on just only look at the IP header.
On the other hand, like CR-LDP, the protocol running on the TCP(UDP)
layer may also make use of the benefit that IP header already notify
the existence of signaling information in the payload of IP packet.
Originally in the CR-LDP protocol, the signaling information is
transferred along the path per hop. If a NE sees the notification of
signaling information in the IP header, it can forward the signaling
packet and processing the signaling information simultaneously. So
the forwarding direction of packet can be done faster than old
mechanisms.
Choi, et. al. [Page 14]
Requirements for IPv6 Signaling as NTLP July 2003
7. References
[RFC1700] J. Reynolds et al. "Assign Numbers", IETF RFC, October 1994.
[RFC1633] R. Braden, et al. "Integrated Services in the Internet
Architecture: an Overview", IETF RFC, June 1994
[RFC2205] R. Braden, Ed. et al. "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", IETF RFC, September
1997.
[RFC2434] T. Narten, et al. "Guidelines for Writing an IANA
Considerations Section in RFCs", IETF RFC, October 1998.
[RFC1883] S. Deering, et al. "Internet Protocol, Version 6 (IPv6)
Specification", December 1995.
[RFC1885] A. Conta, et al. "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", December 1995.
[RFC2710] S. Deering, et al.. "Multicast Listener Discovery (MLD) for
IPv6", October 1999
[RFC2711] C. Partridge, et al.. "IPv6 Router Alert Option", October
1999
[RFC3031] E. Rosen, et al.. "Multiprotocol Label Switching
Architecture", January 2001
[RFC3036] L. Andersson, et al.. "LDP Specification", January 2001
[RFC3209] D. Awduche, et al. "RSVP-TE: Extensions to RSVP for LSP
Tunnels", December 2001.
[RFC3212] B. Jamoussi, et al. "Constraint-Based LSP Setup using LDP",
January 2002.
[RFC3472] Peter Ashwood-Smith, et al. "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Constraint-based Routed
Label Distribution Protocol (CR-LDP) Extensions", January
2003.
[RFC3473] Lou Berger, et al. "Generalized Multi-Protocol Label
Switching (GMPLS)Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", January 2003.
[RFC3372] A.Vemuri, et al. "Session Initiation Protocol for
Telephones(SIP-T) : Context and Architectures", September
2002.
Choi, et. al. [Page 15]
Requirements for IPv6 Signaling as NTLP July 2003
[NSISFW] Ilya Freytsis et al. "Next Steps in Signaling:
Framework", Internet Draft draft-ietf-nsis-fw-02.txt, March
2003.
[NSISREQ] M. Brunner, "Requirements for Signaling Protocols",
Internet Draft draft-ietf-nsis-req-07.txt, March 2003.
[NSISANAYSIS] J. Manner, X. Fu, "Analysis of Existing Quality of
Service Signaling Protocols", Internet Draft draft-
ietf-nsis-signaling-analysis-01.txt, February 2003.
[FlOWLABEL] J. Rajahalme, et al. "IPv6 Flow Label Specification",
Internet Draft draft-ietf-ipv6-flow-label-07.txt, work in
progress, April 2003.
[UNI] The Optical Interworking Forum, "UNI 1.0 Signaling
Specification", December 2001.
Choi, et. al. [Page 16]
Requirements for IPv6 Signaling as NTLP July 2003
8. Author's Addresses
Jun Kyun Choi
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6122
Email: jkchoi@icu.ac.kr
Hyun Hye Lee
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6182
Email: blueming80@icu.ac.kr
Gyu Myoung Lee
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6231
Email: gmlee@icu.ac.kr
Hyoung Jun Kim
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6576
E-mail: khj@etri.re.kr
Ki Shik Park
Electronics and Telecommunications Research Institute (ETRI)
161 Ka Jong-Dong, Yusong-Gu, Taejon
Korea 305-600
Phone: +82-42-860-6041
E-mail: kipark@etri.re.kr
Tae-Gon Noh
Samsung Advanced Institute of Technology (Samsung AIT)
P.O. Box 111, Suwon, Kyoungki
Korea 440-600
Phone: +82-31-280-9621
Email: tgnoh@samsung.com
June-Koo Rhee
Samsung Advanced Institute of Technology (Samsung AIT)
P.O. Box 111, Suwon, Kyoungki
Korea 440-600
Phone: +82-31-280-8193
Choi, et. al. [Page 17]
Requirements for IPv6 Signaling as NTLP July 2003
Email: jk.rhee@samsung.com
Document: draft-choi-ipv6-signaling-req-ntlp-00.txt
Expiration Date: December 2003
Choi, et. al. [Page 18]
