IPNG Working Group Jun Kyun Choi
Internet Draft Gyu Myoung Lee
Document: draft-choi-ipv6-signaling-00.txt Ki Young Jung
Expiration Date: April, 2002 ICU
November 2001
The Features of IPv6 Signaling
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 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.
Abstract
In this memo, we describe the features of IPv6 signaling protocol. We
also discuss the related issues and the need of new signaling. We
will explain the implementation issues in some detail.
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.
Choi et al [Page 1]
Internet Draft The Features of IPv6 Signaling November 2001
Table of Contents
1. Introduction .............................................. 2
2. Features and Considerations of IPv6 Signaling ............. 3
2.1. Features ................................................ 3
2.2. Considerations .......................................... 4
3. Implementations Issues .................................... 6
3.1. Using Router Alert Option ............................... 6
3.2. Using Internet Signaling Message Protocol (ISMP) ........ 7
4. Other Issues .............................................. 8
5. IANA Considerations ....................................... 8
6. Security Considerations ................................... 9
References ................................................... 9
Author's Addresses ........................................... 10
1. Introduction
IPv6 technology is deployed in many fields. But to provide fine QoS
in IPv6 networks, there SHOULD be some signaling mechanisms. So far,
IETF have standardized the RSVP [RFC 2205] signaling to support this,
but that mechanism is weak for the scalability. With regard to
DiffServ [RFC 2475] model, it can solve the scalability problem. But
without signaling, it cannot provide the fine QoS. In other field,
the MPLS [RFC 3031] with aggregated flow labeling and signaling, such
like CR-LDP and RSVP-TE, is a good solution for traffic engineering.
Therefore it can accommodate the killer application such as VPN
services.
To adapt the label switching concept and QoS functionalities, there
are some methodologies like IPngLS(IP next generation Label
Switching) using flow label field in IPv6 basic header.
Someone may want to make use of existing signaling mechanism and the
others may prefer new signaling mechanism. We describe the features
of new IPv6 signaling to use and distribute the information of flow
label and other QoS related parameters. The main issues we are to
address here is the label distribution method and QoS information
delivering method adopted with IPv6 header including IPv6 extension
headers. In order to do this, we suggest the methods how to notify
the existence of signaling information to the routers on the path.
And the effects of each choice will be discussed.
Choi et al [Page 2]
Internet Draft The Features of IPv6 Signaling November 2001
2. Features and Considerations of IPv6 Signaling
2.1. Features
o QoS parameters
Information with QoS controlling is important context of signaling
packet. With aggregated flow concept, IPv6 native signaling can
provide finer QoS granularity than DiffServ model, and more scalable
than IntServ model.
o Resource Reservation
The key role of signaling is to allocate and reserve the network
resource for the purpose of meeting end-to-end QoS requirements along
the entire path. The signaling protocol MUST be able to deal with
such resource allocation requests.
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
with the capability of making intelligent decisions on how resource
allocation SHOULD be controlled.
o Explicit route
In IPv6 specification, there is a route extension header to use
explicit route. Explicit route is important for traffic engineering
in IPv6 networks, so we can use of this option header. In doing so,
signaling packet specify the route with route extension header and
data packet is just switched according to flow label in each router
on the path specified with signaling packet. There is already ROUTE
object in RSVP-TE specification [RSVP-TE 09]. We will discuss it in
section 2.2.
o Scalability
The performance of the signaling 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
o Flow Label Information Distribution
To make use of flow label field as mentioned in [IPNGLS 00] and
identify the flow label between the routers on specific path, label-
binding information SHOULD be delivered between the related routers.
The related routers are on the path of the flow.
Choi et al [Page 3]
Internet Draft The Features of IPv6 Signaling November 2001
Label value is only meaningful between a pair of routers. And the
label value is predetermined before forwarding data packet along the
path.
o Label Stacking
In [IPNGLS 00], label stacking concept is addressed. To enable the
label stacking, the signaling is defined to notify the stacking
information. But we don't consider the concept in this version.
2.2. Considerations
Besides of features of signaling, we must consider the following
issues to make the signaling mechanism.
o Easy to implements
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.
o No problems with non-implemented nodes
To be gradually deployed, we can consider the situation of mixed
nodes that some implement the signaling and the other don't implement
it. Usually signaling mechanisms are ignoring that node and just
forward it.
o Make use of IPv6 features
It is another implementation related issues. IPv6 have a many
features to make use of that to provide some new functions. For
example, one can want to use the IPv6 Routing Option header to send
signaling packet along the desired path rather than the shortest path.
This is reasonable because the IPv6 routers may be implement routing
option header processing component so we can use that without any
additional functional implementations. Also we can think about the
hop-by-hop header to notify routers that the packets have some
signaling and reservation information. These things are already
considered in other signaling mechanism. That means we can use the
IPv6 native features or don't use of them. There is another view-
point related with this. If the same information is transferred with
Choi et al [Page 4]
Internet Draft The Features of IPv6 Signaling November 2001
IPv6 header and payload, there may exist the consistency problems. So
some people want to make one of choices, not both of them.
o QoS parameters
This signaling will apply the QoS parameter per aggregated flow.
To make use of this, state of QoS information SHOLD be maintained per
aggregated flow. Also the adding and deleting of a flow with respect
to the aggregated flow SHOULD be carefully managed. An aggregated
flow is not just used for label-related switching, but also used for
classification information in routers on path. So the QoS parameter
information SHOULD be stored in the router with the information of
relation with an aggregated flow identifier(s).
o 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 is depart 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 in [RSVP -MIPv6]. We just consider the
need of modification or adaptation of that mechanism in our work.
o Inter-operation with other QoS-supporting networks
In this version, we cannot consider this issue.
Choi et al [Page 5]
Internet Draft The Features of IPv6 Signaling November 2001
3. IPv6 Signaling Implementation Issues
This section is going to discuss two methods for carrying the
signaling messages such as RSVP-TE within IPv6 datagrams. Other
signaling messages that use TCP or UDP like CR-LDP, SIP are discussed
in section 4.
3.1. Using Router Alert Option
Router alert option [RFC 2711] within the IPv6 Hop-by-Hop option
header has the semantic "routers should examine the datagram more
closely". Using this option, IPv6 datagrams 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.
[RFC 2460] 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
continue 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 octet code in network byte order with the following
values:
0 Datagram contains a Multicast Listener Discovery
message [RFC 2710].
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.
Choi et al [Page 6]
Internet Draft The Features of IPv6 Signaling November 2001
The described method has some advantages and disadvantages. It is not
necessary to implement the new protocol for signaling. The existing
signaling message is used without change. However, all IPv6 datagrams
containing a signaling message MUST contain this option within the
IPv6 Hop-by-Hop Option Header of such datagrams. The additional
option header is redundant.
3.2. Using Internet Signaling Message Protocol (ISMP)
We propose the new protocol, Internet Signaling Message Protocol
(ISMP), for signaling such as the ICMPv6 [RFC 2463]. ISMP is used to
carry signaling messages. Every ISMP message is preceded by an IPv6
header or by more IPv6 extension headers. The ISMP message is
identified by a Next Header value in the immediately preceding header.
The ISMP 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.
Choi et al [Page 7]
Internet Draft The Features of IPv6 Signaling November 2001
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
IPv6 header. Uses the same values as the
IPv4 Protocol field [RFC 1700 et seq.].
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
[RFC 1700].
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.
Compared with the method using router alert option, 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.
4. Other Issues
We SHOULD consider the interworking issues for transparent transport
of signaling messages between IPv4 and IPv6 network. The mechanisms
that carry application-level signaling (ex. SIP) and other signaling
(ex. CR-LDP) using TCP or UDP SHOULD also be considered. One of way
to do that is that IP header bears the information about the
existence of specific signaling packet in the payload. The benefit of
this concept is that a router on the path can make decision whether
the signaling information is useful for itself and then, consequently,
it can check the payload without processing it in upper layer (ex.
TCP or UDP). So we are on studying to implement our idea over the
existing signaling protocols.
Choi et al [Page 8]
Internet Draft The Features of IPv6 Signaling November 2001
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.
References
[RFC 1700] J. Reynolds et al.. "Assign Numbers", RFC 1700, October
1994
[RFC 2205] R. Braden, Ed. et al.. "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification", RFC 2205,
September 1997
[RFC 2434] T. Narten, et al.. "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998
[RFC 2463] A. Conta, et al.. "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2434, December 1998
[RFC 2475] S. Blake, et al.. "An Architecture for Differentiated
Services", RFC 2475, December 1998
[RFC 2710] S. Deering, et al.. "Multicast Listener Discovery (MLD)
for IPv6", RFC 2710, October 1999
[RFC 2711] C. Partridge, et al.. "IPv6 Router Alert Option", RFC 2711,
October 1999
[RFC 3031] E. Rosen, et al.. "Multiprotocol Label Switching
Architecture", RFC 3031, January 2001
[RSVP-TE 09] Daniel O. Awduche et al.. "RSVP-TE: Extensions to RSVP
for LSP Tunnels-09", Internet Draft, August 2001
[IPNGLS 00] V. Roesler et al.. "IPNGLS - IP Next Generation Label
Switching-00", Internet Draft, September, 2001
[RSVP-MIPv6 00] Charles Qi Shen, et al.. "An Interoperation Framework
for Using RSVP in Mobile IPv6 Networks-00", Internet Draft,
July 2001
Choi et al [Page 9]
Internet Draft The Features of IPv6 Signaling November 2001
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
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
Ki Young Jung
Information and Communications University (ICU)
58-4 Hwa Ahm Dong, Yusong, Taejon
Korea 305-732
Phone: +82-42-866-6182
Email: jjungki@icu.ac.kr
Full Copyright Statement
"Copyright (C) The Internet Society (date)". All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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
revoked by the Internet Society or its successors or assigns.
Document: draft-ietf-ipv6-signaling-00.txt
Expiration Date: April 2002
Choi et al [Page 10]