Internet DRAFT - draft-sanda-nsis-path-type
draft-sanda-nsis-path-type
Next Steps in Signaling (nsis) T. Sanda
Internet-Draft T. Ue
Expires: April 27, 2006 H. Cheng
Panasonic
October 24, 2005
Path type support for NSIS signaling
draft-sanda-nsis-path-type-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
NSIS state management needs to track data path changes and update the
states along the affected data paths. However, in certain scenarios,
there are multiple concurrent paths involved in the communication.
In this case, the normal NSIS scheme does not provide sufficient
support for the state manipulation. Therefore, extra functionality
for data path identification and distinction is necessary. In
current Internet, with the increasing use of multi-homing devices and
Sanda, et al. Expires April 27, 2006 [Page 1]
Internet-Draft Path type support for NSIS October 2005
the employment of Mobile IP, the above issue is getting more
prominent. This draft discusses in detail the problems and issues
involved in the NSIS state management relevant to the data path
differentiation. Specific scenarios for multi-homing and Mobile IP
route optimization are studied. Potential solution and its impacts
on current NSIS protocol design are discussed as well.
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Problems in multi-interface terminal scenario . . . . . . 7
4.2. Problems in Mobile IP RO scenario . . . . . . . . . . . . 8
5. Requirement of signaling handling for multiple paths . . . . . 11
6. Path Type ID . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Path Type ID for Multi-link terminal scenario . . . . . . 13
6.2. Path Type ID utilization for Mobile IP scenario . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative Reference . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Sanda, et al. Expires April 27, 2006 [Page 2]
Internet-Draft Path type support for NSIS October 2005
1. Conventions used in this document
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 [1].
Sanda, et al. Expires April 27, 2006 [Page 3]
Internet-Draft Path type support for NSIS October 2005
2. Introduction
In the defined NSIS framework [2], a two-layer architecture is used,
wherein the NTLP layer handles the general message routing and
transport and NSLP layer carries out the actual signaling
application. The GIMPS draft [3] defines the NTLP layer, and the QoS
NSLP draft [4] specifies an instance of the NSLP signaling
application for the QoS provisioning and control. These drafts
specify that each signaling path state is managed with two
identifiers, i.e. the flow identifier (Flow ID) and the session
identifier (Session ID).
In certain scenarios, communication nodes utilize plural data paths
for one session. For example, a terminal that has multiple
communication interfaces may communicate with the Correspondent Node
(CN) using multiple data paths via multiple links for one session.
For these multi-homed cases, the network may observe several path
reservations even without any terminal movement. Therefore, special
techniques have to be employed to distinguish this from an actual
mobility event, so that no mobility handling procedure would be
triggered. Another example is the Route Optimization (RO) in the
Mobile IP environment. When a successful RO is performed, data will
flow directly between the CN and the Mobile Node (MN) without going
through the Home Agent (HA). Since the RO procedure makes use of the
triangular (TR) path (path via the HA), it will always happen after
the TR path is set up. Even after RO procedure is completed, TR path
will be used when RO path is down. This means that the MN may use
multiple paths to communicate with the CN. In the RO procedure,
there is always a data path change involved, even though there is no
actual address change.
The first scenario where Flow ID doesn't work is when the address
information cannot be represented by a single Flow ID, e.g., the
multihoming case, or multi-thread case. In these cases, Flow ID in
its current form is incapable of carrying the full information for
the packet classification. Another scenario is when the NSIS
signaling needs to be carried out before the actual data traffic flow
starts. It is possible that at this point of time, some address
information is not yet available, and thus the Flow ID cannot be
generated according to the current specified method. This would
happen most likely in the case of make-before-break reservation on
predictive paths. In yet another scenario, the address information
involved in the Flow ID generation may change during the course of
the session, e.g. the port number or the DSCP/TOS fields. This does
not necessary mean a route change, and should not always trigger the
state change along the data path. Therefore, the Flow ID and the
traffic classification information are not always synchronized.
Sanda, et al. Expires April 27, 2006 [Page 4]
Internet-Draft Path type support for NSIS October 2005
It is obvious from the above that the Flow ID and Session ID defined
[3] [4] are not sufficient to support these more complicated
reservation management, when multiple data paths are involved. In
this draft, details of the problems and requirements for signaling
handling multiple paths are discussed. A possible solution using a
Path Type ID is also introduced.
Sanda, et al. Expires April 27, 2006 [Page 5]
Internet-Draft Path type support for NSIS October 2005
3. Terminology
The Terminology defined in [2], [3] and [4] applies to this draft.
In addition, the following terms are used:
TR path: Triangular Path. A route between MN and CN with tunneled
RO path: Route Optimized path. A direct route between MN and CN
Sanda, et al. Expires April 27, 2006 [Page 6]
Internet-Draft Path type support for NSIS October 2005
4. Problem Statement
This section introduces two scenarios that multiple data paths are
used for one session, one is multi-interface terminal case and the
other is Mobile IP RO case, and shows examples NSIS state management
cannot work properly.
4.1. Problems in multi-interface terminal scenario
It is common nowadays for a terminal to be equipped with multiple
communication technologies. For example, it is nature to have a
combination of Ethernet, Wireless LAN, InfraRed, and Bluetooth
interfaces installed on a laptop. Those best selling PDAs usually
have cellular and Wireless LAN interfaces. In this draft, a multi-
interface terminal is defined as one that can utilize more than two
interfaces for one communication session. With the advance of the
interworking study, e.g. IEEE802.11u and IEEE802.21, this may become
a normal practice. In this case, multiple data paths are used for
the communication simultaneously. Furthermore, if the interfaces are
wireless, such as 802.11 WLAN, UMTS and so on, each interface can
switch its attachment point independently. This means data paths are
changed separately.
The scenario discussed here is shown in Figure 1. MN is
communicating with CN using two interfaces, "p" and "s", for one
session. Interface "p" has a data path (Path1) via AP1, AR1 and QNE1
while interface "s" has a data path (Path2) via AP2, AR2 and QNE1.
According to the NSIS draft [3] [4], QoS state would be installed on
each data path and the same Session ID and different Flow IDs would
be allocated for them.
Sanda, et al. Expires April 27, 2006 [Page 7]
Internet-Draft Path type support for NSIS October 2005
+--------+ +--------+
| CN | | CN |
+--------+ +--------+
* * * * *
* * * * *
+--------+ +--------+
| QNE1 | | QNE1 |
+--------+ +--------+
* * * * *
* * * * *
* * * * *
Path1* *Path2 Path1* *Path2 *Path3
* * * * *
* * * * *
* * * * *
+---+ +---+ +---+ +---+ +---+
|AR1| |AR2| |AR1| |AR2| |AR3|
+---+ +---+ +---+ +---+ +---+
* * * * *
+---+ +---+ +---+ +---+ +---+
|AP1| |AP2| |AP1| |AP2| |AP3|
+---+ +---+ +---+ +---+ +---+
* * * X *
* * * X *
* * * X *
* * * X*
p=> | | <=s p=> | | <=s
+------+ +------+
| MN | | MN |
+------+ +------+
(a) (b)
Figure 1. Multi-interface terminal scenario
When the interface "s" performs a handover from AP2 to AP3 as shown
in Figure 1(b), QoS state for Path2 is replaced by Path3, while Path1
should be maintained. In this case, QNE1 needs to know which path/
state must be replaced by Path3. However, since Flow ID for Path1,
Path2 and Path3 are different and Session IDs for all paths are the
same, it is impossible for QNE1 to know how to operate each path.
4.2. Problems in Mobile IP RO scenario
As described in MIPv6 [5], the RO procedures will be performed if
Sanda, et al. Expires April 27, 2006 [Page 8]
Internet-Draft Path type support for NSIS October 2005
both the MN and the CN supports it. With optimization, data traffic
will flow directly between MN and CN without going through the HA.
This improves the efficiency of network resources utilization, and
reduces the communication dependency on the MN's Home network.
A nature of data path change in RO procedure is different from that
resulted from a MN changing its point of attachment. Even after data
path is changed from TR path to RO path, they are still related since
they have different characteristics. A TR path will be reused when
an RO path is aborted as well as when MN moves to a new location.
When NSIS QoS state is installed in RO path, reservation state for
the old path, i.e. TR path, may be required to be kept because it
will be reused. Simultaneously, reserved resource for TR path may
have to be reduced not to waste limited resources. Signaling
management for each path would also need to be done separately,
depending on control policies.
Reservation state handling for TR path and RO path requires more
flexibility than state handling for path changes caused by MN's move
or re-routing. To realize flexible operation, it is desirable that
every NSIS Node could differentiate RO path and TR path reservation
state with NSIS protocols.
Figure 2 shows one example scenario of a TR path and an RO path.
When NSIS QoS state is made on a RO path (path "y"), a crossover node
(CRN), e.g. a QNE3 needs to operate a TR path (path "x") properly.
However, as it cannot differentiate a TR path and an RO path,
operation for a TR path cannot be done.
Furthermore, when MN moves to a new location (Figure 3), TR path
(path "z") followed by RO path (path "w") will be utilized. This
case, a CRN, such as QNE3 does not know which path have to be
released because it cannot distinguish a path change caused by
handover from the one caused by RO procedures.
Sanda, et al. Expires April 27, 2006 [Page 9]
Internet-Draft Path type support for NSIS October 2005
+----+x x x x +----+x x x x x+----+x x x+----+
| HA | |QNE2| |QNE3| | CN |
| | | | | |y y y| |
+----+ +----+ y +----+ +----+
x y
x y
+----+ y
|QNE1| y
| | y
+----+
x y
x y
+----+
|AR1 |
+----+
x y
+----+
| MN | xxxxx TR at Location1
+----+ yyyyy RO at Location1
Figure 2. An example of TR path and RO path
+----+x x x x +----+x x x x x+----+x x x+----+
| HA |z z z z |QNE2|z z z z z|QNE3|z z z| CN |
| | | | | |y y y| |
+----+ z +----+ y +----+w w w+----+
x z y w
x z y w
+----+ y z +----+
|QNE1| y z |QNE4|
| | y z | |
+----+ +----+
x y z w
x y z w
+----+ +----+
|AR1 | |AR2 |
+----+ +----+
x y z w xxxxx TR at Location1
+----+ +----+ yyyyy RO at Location1
| MN | ------> | MN | zzzzz TR at Location2
+----+ +----+ wwwww RO at Location2
Figure 3. An example of TR path and RO path with MN's movement
Sanda, et al. Expires April 27, 2006 [Page 10]
Internet-Draft Path type support for NSIS October 2005
5. Requirement of signaling handling for multiple paths
In order to handle signaling in scenarios described in previous
sections, the NSIS signaling scheme must be modified to meet the
following requirements:
1) The signaling identifiers must be able to distinguish each flows/
paths involved in the same session. For example, in Figure 1, Path
1, Path 2, and Path 3 must be clearly separated.
2) The signaling identifiers must be able to reflect the dependency
and relationship between the flows/paths involved in the same
session. For example, in Figure 1, Path 1 and Path 2 are serving the
same session simultaneously, and thus should co-exist. Whereas, Path
2 and Path 3 are two different paths for the same interface at
different time, and thus, Path 3 should replace Path 2.
The first requirement is achieved in the current NSIS framework by
using different Flow IDs for the different paths. Therefore, for the
three paths, three separate Flow IDs would be generated, and those
help to distinguish the different paths.
However, the current NSIS have problem to meet the second requirement
completely. Since the paths are all serving the same session, it is
nature to use the same Session ID for all the signaling. This could
indicate to the NSIS aware nodes, e.g QNEs, that the paths are
belonging to the same session. By unsetting the REPLACE flag of the
QoS NSLP [4], the signaling is able to indicate to the QNEs that the
paths should co-exist. But, this cannot indicate to the QNEs that
the Path 3 should replace Path 2. If the signaling message for Path
3 has the REPLACE flag set, it would replace states of both Path 2
and Path 1 over the common section. This is an undesired situation.
In the NSIS Operation Over IP Tunnel draft [6], an
ASSOCIATE_FLOW_SESSION object is proposed to further indicate the
relationship between flows within a session, i.e. with the same
Session ID. This will help to meet the requirement 2. However, this
new object, which is big (of the size of Flow ID), needs to be
embedded into the signaling for all the flows that has relationship
with each other. It would be a overhead for the signaling, once the
relationships between flows are complicated, it would be quite costly
to the signaling.
Another possible choice is to use different Session IDs in the
signaling. For example, in Figure 1, since the Path 2 and Path 3
cannot co-exist, they will use the same Session ID. And Path 1 and
Path 2 should co-exist, and thus would use different Session IDs. In
order to indicate their relationship, the BOUND_SESSION_ID object of
Sanda, et al. Expires April 27, 2006 [Page 11]
Internet-Draft Path type support for NSIS October 2005
QoS NSLP [4] could be used to indicate that the two sessions should
be bound so that resources could be shared. This way, the
requirement 2 would be met. However, it also creates high overhead
for the signaling, since every message needs to carry the
BOUND_SESSION_ID object, and every QNE needs to support the session
binding.
In this draft a simply yet effective method is proposed. Instead of
introducing the full-fledged binding/associate object, a simple
object Path Type ID is used in conjunction with the use of same
Session ID and different Flow IDs for the different flow/paths. This
way, the requirement 2 can be met with easy. Following section
describe the use of such solution with different scenarios.
Sanda, et al. Expires April 27, 2006 [Page 12]
Internet-Draft Path type support for NSIS October 2005
6. Path Type ID
In order to introduce the dependency and relationship between the
flows/paths involved in the same session, a new identifier called
"Path Type ID" can be utilized. Path Type ID could be a few bit
values or code which is carried by signaling messages and stored in
QNEs with other identifiers. Since it is small, certain reserved
fields of NSIS message header could be used to carry it. Therefore,
minimum overhead would be added to the signaling.By comparing Path
Type ID as well as Session ID and Flow ID, QNEs can operate multiple
co-related paths properly.
6.1. Path Type ID for Multi-link terminal scenario
In the scenario discussed in section 2.1, it is required that QNE1
determines which path/state should be replaced or maintained with
minimal signaling exchanges. For this purpose, Path Type ID is
utilized. In the scenario in Figure 1(b), Path Type ID for Path2 and
Path3 is an identical values or code, which is different from that
for Path1. QNE1 in Figure 1 (b) can replace a path2 to a path3
because it explicitly knows these two paths have the same Path Type
ID value.
MN can decide Path Type ID by information of interfaces, i.e. Path
Type ID in this case shows the interface where the signaling message
comes from or goes to.
6.2. Path Type ID utilization for Mobile IP scenario
As discussed in Sec. 2.2, current NSIS protocol design cannot
indicate the complicated relationship between TR path and RO path in
the signaling. Since the RO is common for a MIPv6 enable network,
NSIS protocols cannot support mobility properly without a solution to
this problem.
Path Type ID used in this scenario identifies the TR and RO paths.
In the scenario in Figure 3, Path Type ID for paths "x" and "z" is an
identical code or number (e.g., "TR") while Path Type ID for paths
"y" and "w" is also identical but different from that for paths "x"
and "z" (e.g., "RO").
MN can decide Path Type ID by the information from MIP layer, e.g.
receiving Binding ACK message, and then set the Path Type ID in
RESERVE message.
Flexible operation for TR and RO paths is also possible. Even when
MN A moves to location 2, QNEs could still distinguish the old path
and new path by comparing Path Type ID and Flow ID. However, the
Sanda, et al. Expires April 27, 2006 [Page 13]
Internet-Draft Path type support for NSIS October 2005
method to explicitly associate TR path and RO path at the same
location may be required. For supporting this functionality, an
object to decide MN's location, such as mobility_event_counter
mentioned in Applicability Statement draft [7] could be useful.
Sanda, et al. Expires April 27, 2006 [Page 14]
Internet-Draft Path type support for NSIS October 2005
7. Security Considerations
Security should be considered in the NTLP/NSLP specifications as an
integrated part. Specific issues in Route Optimization case will be
essentially covered by the Route Optimization security in Mobile IPv6
[5]. Future version of this draft would discuss the relevant
security requirements for the solutions in detail.
Sanda, et al. Expires April 27, 2006 [Page 15]
Internet-Draft Path type support for NSIS October 2005
8. Conclusion
This draft discussed potential problems related to NSIS QoS state
management for multiple paths caused by multi-interface terminal and
Mobile IP RO procedures. As one possible solution, Path Type ID was
introduced so that QNEs could perform flexible state management for
each path.
This draft also includes some other discussions relevant to the
problems on usage of Flow ID as a packet classifier. Use cases are
analyzed with regarding to the requirements.
Sanda, et al. Expires April 27, 2006 [Page 16]
Internet-Draft Path type support for NSIS October 2005
9. Acknowledgements
This section contains the acknowledgements.
10. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Hancock, R., "Next Steps in Signaling (NSIS): Framework",
RFC 4080, Informational , June 2005.
[3] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signaling Transport", Internet Draft draft-ietf-nsis-ntlp-08,
Work in progress , September 2005.
[4] Manner, J., "NSLP for Quality-of-Service Signaling", Internet
Draft draft-ietf-nsis-qos-nslp-07, Work in progress , July 2005.
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility support in
IPv6", RFC 3775, June 2004.
[6] Shen, C., "NSIS Operation Over IP Tunnels", Internet
Darf draft-shen-nsis-tunnel-00, Work in Progress , July 2005.
[7] Lee, S., "Applicability Statement of NSIS Protocol in Mobile
Environments", Internet
Draft draft-ietf-nsis-applicability-mobility-signaling-02, Work
in progress , July 2005.
Sanda, et al. Expires April 27, 2006 [Page 17]
Internet-Draft Path type support for NSIS October 2005
Authors' Addresses
Takako Sanda
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3, Hikarino-oka, Yokosuka City
Kanagawa 239-0847
Japan
Phone: +81 46 840 5764
Email: sanda.takako@jp.panasonic.com
Toyoki Ue
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3, Hikarino-oka, Yokosuka City
Kanagawa 239-0847
Japan
Phone: +81 46 840 5816
Email: ue.toyoki@jp.panasonic.com
Hong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534415
Singapore
Phone: +65 6550 5477
Email: hong.cheng@sg.panasonic.com
Sanda, et al. Expires April 27, 2006 [Page 18]
Internet-Draft Path type support for NSIS October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sanda, et al. Expires April 27, 2006 [Page 19]
