draft-ietf-nsis-tunnel-10.txt   draft-ietf-nsis-tunnel-11.txt 
IETF Next Steps in Signaling C. Shen IETF Next Steps in Signaling C. Shen
Internet-Draft H. Schulzrinne Internet-Draft H. Schulzrinne
Intended status: Experimental Columbia U. Intended status: Experimental Columbia U.
Expires: October 20, 2010 S. Lee Expires: December 5, 2010 S. Lee
J. Bang J. Bang
Samsung AIT Samsung AIT
April 18, 2010 June 3, 2010
NSIS Operation Over IP Tunnels NSIS Operation Over IP Tunnels
draft-ietf-nsis-tunnel-10.txt draft-ietf-nsis-tunnel-11.txt
Abstract Abstract
NSIS QoS signaling enables applications to perform QoS reservation NSIS Quality of Service (QoS) signaling enables applications to
along a data flow path. When the data flow path contains IP tunnel perform QoS reservation along a data flow path. When the data flow
segments, NSIS QoS signaling has no effect within those tunnel path contains IP tunnel segments, NSIS QoS signaling has no effect
segments and the resulting QoS-untended tunnel segments could become within those tunnel segments and the resulting QoS-untended tunnel
the weakest QoS link which may invalidate the QoS efforts in the rest segments could become the weakest QoS link which may invalidate the
of the end-to-end path. The problem with NSIS signaling within the QoS efforts in the rest of the end-to-end path. The problem with
tunnel is caused by the tunnel encapsulation which masks packets' NSIS signaling within the tunnel is caused by the tunnel
original IP header fields. Those original IP header fields are encapsulation which masks packets' original IP header fields. Those
needed to intercept NSIS signaling messages and classify QoS data original IP header fields are needed to intercept NSIS signaling
packets. This document defines a solution to this problem by mapping messages and classify QoS data packets. This document defines a
end-to-end QoS session requests to corresponding QoS sessions in the solution to this problem by mapping end-to-end QoS session requests
tunnel, thus extending the end-to-end QoS signaling into the IP to corresponding QoS sessions in the tunnel, thus extending the end-
tunnel segments. to-end QoS signaling into the IP tunnel segments.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2010. This Internet-Draft will expire on December 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 5 3.1. IP Tunneling Protocols . . . . . . . . . . . . . . . . . . 6
3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 7 3.2. NSIS QoS Signaling in the Presence of IP Tunnels . . . . . 8
4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 9 4.1. Design Requirements . . . . . . . . . . . . . . . . . . . 10
4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 10 4.2. Overall Design Approach . . . . . . . . . . . . . . . . . 11
4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 12 4.3. Tunnel Flow ID for Different IP Tunneling Protocols . . . 13
5. NSIS Operation over Tunnels with Pre-configured QoS 5. NSIS Operation over Tunnels with Pre-configured QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 13 5.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 14
5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 14 5.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 15
6. NSIS Operation over Tunnels with Dynamically Created QoS 6. NSIS Operation over Tunnels with Dynamically Created QoS
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 16 6.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 16
6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 18 6.2. Receiver-initiated Reservation . . . . . . . . . . . . . . 19
7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 21 7. NSIS-Tunnel Signaling Capability Discovery . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
IP tunneling is a technique that allows a packet to be encapsulated IP tunneling is a technique that allows a packet to be encapsulated
and carried as payload within an IP packet. The resulting and carried as payload within an IP packet. The resulting
encapsulated packet is called an IP tunnel packet, and the packet encapsulated packet is called an IP tunnel packet, and the packet
being tunneled is called the original packet. In typical scenarios, being tunneled is called the original packet. In typical scenarios,
IP tunneling is used to exert explicit forwarding path control (e.g., IP tunneling is used to exert explicit forwarding path control (e.g.,
in Mobile IP [RFC3220]), facilitate the secure IP delivery in Mobile IP [RFC3344]), facilitate the secure IP delivery
architecture (e.g., in IPSEC [RFC2401]), and help packet routing in architecture (e.g., in IPSEC [RFC4301]), and help packet routing in
IP networks of different characteristics (e.g., between IPv6 and IPv4 IP networks of different characteristics (e.g., between IPv6 and IPv4
networks [RFC4213]). networks [RFC4213]).
This document considers the situation when the packet being tunneled This document considers the situation when the packet being tunneled
contains a Next Step In Signaling (NSIS) [RFC4080] message. NSIS is contains a Next Step In Signaling (NSIS) [RFC4080] message. NSIS is
an IP network layer signaling architecture consisting of a Generic an IP network layer signaling architecture consisting of a Generic
Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] sub-layer
for signaling transport, and an NSIS Signaling Layer Protocol (NSLP) for signaling transport, and an NSIS Signaling Layer Protocol (NSLP)
sub-layer customizable for different applications. We focus on the sub-layer customizable for different applications. We focus on the
Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides Quality of Service (QoS) NSLP [I-D.ietf-nsis-qos-nslp] which provides
skipping to change at page 4, line 21 skipping to change at page 5, line 21
discover whether a tunnel end-point node supports the NSIS-tunnel discover whether a tunnel end-point node supports the NSIS-tunnel
interoperation mechanism defined in this document. Section 8 interoperation mechanism defined in this document. Section 8
discusses IANA considerations and Section 9 considers security. discusses IANA considerations and Section 9 considers security.
2. Terminology 2. Terminology
This document uses terminology defined in [RFC2473], This document uses terminology defined in [RFC2473],
[I-D.ietf-nsis-ntlp], and [I-D.ietf-nsis-qos-nslp]. In addition, the [I-D.ietf-nsis-ntlp], and [I-D.ietf-nsis-qos-nslp]. In addition, the
following terms are used: following terms are used:
IP Tunnel: A tunnel configured as a virtual link between two IP
nodes, on which the encapsulating protocol is IP.
Tunnel IP Header: The IP header prepended to the original packet Tunnel IP Header: The IP header prepended to the original packet
during encapsulation. It specifies the tunnel end-points as during encapsulation. It specifies the tunnel end-points as
source and destination. source and destination.
Tunnel Specific Header: The header fields inserted by the Tunnel Specific Header: The header fields inserted by the
encapsulation mechanism after the tunnel IP header and before the encapsulation mechanism after the tunnel IP header and before the
original packet. These headers may or may not exist depending on original packet. These headers may or may not exist depending on
the specific tunnel mechanism used. the specific tunnel mechanism used.
Tunnel Intermediate Node (Tmid): A node which resides in the middle Tunnel Intermediate Node (Tmid): A node which resides in the middle
of the forwarding path between the tunnel entry-point node and the of the forwarding path between the tunnel entry-point node and the
tunnel exit-point node. tunnel exit-point node.
IP Tunnel: A tunnel configured as a virtual link between two IP
nodes, on which the encapsulating protocol is IP.
Flow Identifier (Flow ID): The set of header fields which is used to Flow Identifier (Flow ID): The set of header fields which is used to
identify a [Data] flow. For example, it may include flow sender identify a [data] flow. For example, it may include flow sender
and receiver addresses, protocol and port numbers. and receiver addresses, protocol and port numbers.
End-to-end [QoS] Signaling: The signaling process that manipulates End-to-end [QoS] Signaling: The signaling process that manipulates
the QoS control information in the end-to-end path from the flow the QoS control information in the end-to-end path from the flow
sender to the flow receiver. When the end-to-end flow path sender to the flow receiver. When the end-to-end flow path
contains tunnel segments, this document uses end-to-end [QoS] contains tunnel segments, this document uses end-to-end [QoS]
signaling to refer specially to the [QoS] signaling outside the signaling to refer specially to the [QoS] signaling outside the
tunnel segments. tunnel segments.
Tunnel [QoS] Signaling: The signaling process that manipulates the Tunnel [QoS] Signaling: The signaling process that manipulates the
QoS control information in the path inside a tunnel, between the QoS control information in the path inside a tunnel, between the
tunnel entry-point and the tunnel exit-point nodes. tunnel entry-point and the tunnel exit-point nodes.
[Adjacent] NSIS Peer: The next node along the signaling path, in the
upstream or downstream direction, with which a NSIS node
explicitly interacts.
NSIS-aware Node: A node that supports NSIS signaling. NSIS-aware Node: A node that supports NSIS signaling.
NSIS-aware Tunnel End-point Node: A tunnel end-point node which is NSIS-aware Tunnel End-point Node: A tunnel end-point node which is
also an NSIS node. also an NSIS node.
NSIS-tunnel-aware [Tunnel] End-point Node: An NSIS-aware Tunnel End- NSIS-tunnel-aware [Tunnel] End-point Node: An NSIS-aware Tunnel End-
point node which also supports the mechanism for NSIS operating point node which also supports the mechanism for NSIS operating
over IP tunnels defined in this document. over IP tunnels defined in this document.
3. Problem Statement 3. Problem Statement
skipping to change at page 23, line 28 skipping to change at page 24, line 24
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (work in progress), January 2010.
11.2. Informative References 11.2. Informative References
[I-D.ietf-nsis-applicability-mobility-signaling]
Sanda, T., Fu, X., Jeong, S., Manner, J., and H.
Tschofenig, "NSIS Protocols operation in Mobile
Environments",
draft-ietf-nsis-applicability-mobility-signaling-15 (work
in progress), March 2010.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-24 (work in progress),
April 2010.
[I-D.ietf-nsis-qspec]
Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
Template", draft-ietf-nsis-qspec-24 (work in progress),
January 2010.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702, Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994. October 1994.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
skipping to change at page 24, line 20 skipping to change at page 24, line 46
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996. October 1996.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997. February 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000. "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
January 2002. August 2002.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004. "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005. RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
 End of changes. 19 change blocks. 
73 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/