One document matched: draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01.txt
Differences from draft-kumaki-murai-ccamp-rsvp-te-l3vpn-00.txt
Network Working Group
Internet Draft K. Kumaki, Ed.
Category: standards track KDDI Corporation
Created: October 23, 2009 T. Murai, Ed.
Expires: April 23, 2010 FURUKAWA NETWORK
SOLUTION CORP.
T. Yamagata
KDDI Corporation
C. Sasaki
KDDI R&D Labs
Support for RSVP-TE in L3VPNs
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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.
Abstract
It is highly desirable for VPN customers to be able to establish
their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a
scenario, it is necessary that RSVP control messages, such as Path
messages and Resv messages, are appropriately handled by the PE
routers. This document defines new object types in SESSION,
SENDER_TEMPLATE and FILTERSPEC object to establish a customer MPLS
TE LSP in the context of BGP/IP-VPNs and describes a procedure of
RSVP control messages including the new object types.
Conventions used in this document
K.Kumaki, et al. [Page 1]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
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].
Table of Contents
1. Introduction..................................................2
2. Problem Statement.............................................3
3. Terminology...................................................4
4. Protocol Extensions and Procedures............................4
4.1 Object Definitions........................................4
4.1.1 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object
..............................................................4
4.1.2 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE
objects.......................................................6
4.1.3 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC
objects.......................................................7
4.1.4 VPN-IPv4 and VPN-IPv6 RSVP_HOP objects..................7
4.2 Handling..................................................7
4.2.1 Path Message Processing at Ingress PE...................7
4.2.2 Path Message Processing at Egress PE....................8
4.2.3 Resv Processing at Egress PE............................9
4.2.4 Resv Processing at Ingress PE...........................9
5. Security Considerations.......................................9
6. IANA Considerations...........................................9
7. References...................................................10
7.1 Normative References.....................................10
7.2 Informative References...................................10
8. Acknowledgments..............................................10
9. Author's Addresses...........................................10
1. Introduction
Service Providers have requirements to support CE-CE MPLS TE LSP
establishments in the context of a BGP/MPLS IP-VPNs. [E2E-RSVP-TE]
[RFC3209] defines extensions to RSVP for establishing label switched
paths (LSPs) in MPLS networks. In order to establish a customer MPLS
TE LSP over BGP/MPLS IP-VPNs, it is necessary that RSVP control
messages, such as Path messages and Resv messages described in
[RFC3209], are appropriately handled by the PE routers.
[RSVP-L3VPN] defines new types of the existing objects (i.e. SESSION,
SENDER_TEMPLATE, FILTERSPEC and RSVP_HOP) described in [RFC2205] to
establish reservations for customer flows in the context of a
BGP/MPLS IP-VPNs. Also, as described in section 7.4 of [RSVP-L3VPN],
the same approach is used in this draft.
This document defines new object types in SESSION, SENDER_TEMPLATE
and FILTERSPEC object to establish a customer MPLS TE LSP in the
context of BGP/IP-VPNs and describes a procedure of RSVP control
K.Kumaki, et al. [Page 2]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
messages including new object types. The new object types are defined
in section 4.1 and the specific procedure is described in section
4.2.
2. Problem Statement
Customer MPLS TE LSPs in the context of BGP/MPLS IP-VPNs are shown in
figure 1. Here, we make the following set of assumptions.
1. VPN1 and VPN2 are completely different customers.
2. CE1 and CE3 are head-end routers.
3. CE2 and CE4 are tail-end routers.
4. A same address (e.g., 192.0.2.1) is assigned at CE2 and CE4.
<--------a customer MPLS TE LSP for VPN1-------->
....... .......
. --- . --- --- --- --- . --- .
.|CE1|----|PE1|----|P1 |-----|P2 |----|PE2|-----|CE2|.
. --- . --- --- --- --- . --- .
....... | | .......
(VPN1) | | (VPN1)
| |
....... | | .......
. --- . | | . --- .
.|CE3|------+ +-------|CE4|.
. --- . . --- .
....... .......
(VPN2) (VPN2)
<--------a customer MPLS TE LSP for VPN2-------->
^ ^
| |
vrf instance vrf instance
<-customer-> <---BGP/MPLS IP-VPN---> <-customer->
network network
Figure 1 Customer MPLS TE LSPs in the context of BGP/MPLS IP-VPNs
Consider that customers in VPN1 and VPN2 establish a customer MPLS TE
LSP between their sites (i.e., between CE1 and CE2, between CE3 and
CE4) In this case, CE1 and CE3 send a Path message to PE1 to
establish customer MPLS TE LSPs between CE1 and CE2, CE3 and CE4,
respectively. After receiving these messages, PE1 can identify each
Path message (i.e., a message for VPN1 and a message for VPN2) from
each incoming interface. Afterwards, PE1 forwards the messages to PE2
by routing information described in [RFC4364][RFC4659]. PE2, however,
can not identify each Path message from current specification of
K.Kumaki, et al. [Page 3]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
[RFC3209] (i.e., the message for VPN1 and the message for VPN2).
Therefore, PE2 can not forward to appropriate CEs per VPN.
Also, Resv messages per VPN can not be identified at PE1 due to the
above reason.
In order to distinguish between the VPN1 Path/Resv messages and the
VPN2 Path/Resv messages, an identifier in Path/Resv messages is
required.
In this document, new object types in SESSION, SENDER_TEMPLATE and
FILTERSPEC object as an identifier are defined to distinguish
Path/Resv messages per VPN in the context of BGP/MPLS IP-VPNs.
3. Terminology
LSP: Label Switched Path
TE LSP: Traffic Engineering Label Switched Path
MPLS TE LSP: Multi Protocol Label Switching TE LSP
Customer MPLS TE LSP: an end-to-end MPLS TE LSP for customers
CE: Customer Edge Equipment
PE: Provider Edge: Provider Edge Equipment that has direct
connections to CEs from the Layer3 point of view.
4. Protocol Extensions and Procedures
4.1 Object Definitions
4.1.1 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object
The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) SESSION Object appears in RSVP
messages that ordinarily contain a SESSION Object and are sent
between ingress PE and egress PE in either direction. The object MUST
NOT be included in any RSVP messages that are sent outside of the
provider's backbone.
The LSP_TUNNEL_VPN-IPv6 SESSION Object is analogous to the
LSP_TUNNEL_VPN-IPv4 SESSION Object, using a VPN-IPv6 address
([RFC4659]) instead of a VPN-IPv4 address ([RFC4364]).
The formats of the objects are as follows:
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
K.Kumaki, et al. [Page 4]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| VPN-IPv4 tunnel end point address (12 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| VPN-IPv6 tunnel end point address |
+ +
| (24 bytes) |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VPN-IPv4 tunnel end point address (respectively VPN-IPv6 tunnel
end point address) field contains an address of the VPN-IPv4
(respectively VPN-IPv6) address family encoded as specified in
[RFC4364](respectively [RFC4659]).
K.Kumaki, et al. [Page 5]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
The Tunnel ID and Extended Tunnel ID are identical to the same fields
in the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 SESSION objects
([RFC3209]).
4.1.2 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE
objects
The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) SENDER_TEMPLATE Object appears
in RSVP messages that ordinarily contain a SENDER_TEMPLATE Object and
are sent between ingress PE and egress PE in either direction (such
as Path, PathError, and PathTear). The object MUST NOT be included
in any RSVP messages that are sent outside of the provider's
backbone. The format of the object is as follows:
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| VPN-IPv4 tunnel sender address (12 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| VPN-IPv6 tunnel sender address |
+ +
| (24 bytes) |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K.Kumaki, et al. [Page 6]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
The VPN-IPv4 tunnel sender address (respectively VPN-IPv6 tunnel
sender address) field contains an address of the VPN-IPv4
(respectively VPN-IPv6) address family encoded as specified in
[RFC4364](respectively [RFC4659]).
The LSP ID is identical to the LSP ID field in the LSP_TUNNEL_IPv4
and LSP_TUNNEL_IPv6 SENDER_TEMPLATE objects ([RFC3209]).
4.1.3 LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC objects
The LSP_TUNNEL_VPN-IPv4 (or VPN-IPv6) FILTER_SPEC Object appears in
RSVP messages that ordinarily contain a FILTER_SPEC Object and are
sent between ingress PE and egress PE in either direction (such as
Resv, ResvError, and ResvTear). The object MUST NOT be included in
any RSVP messages that are sent outside of the provider's backbone.
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
The format of the LSP_TUNNEL_VPN-IPv4 FILTER_SPEC Object is identical
to the LSP_TUNNEL_VPN-IPv4 SENDER_TEMPLATE Object.
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
The format of the LSP_TUNNEL_VPN-IPv6 FILTER_SPEC Object is identical
to the LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE Object.
4.1.4 VPN-IPv4 and VPN-IPv6 RSVP_HOP objects
The format of the VPN-IPv4 and VPN-IPv6 RSVP_HOP objects are
identical to objects described in [RSVP-L3VPN].
4.2 Handling
It assumes that ingress PEs and egress PEs in the context of BGP/MPLS
IP-VPNs have RSVP capabilities.
4.2.1 Path Message Processing at Ingress PE
When a Path message arrives at the ingress PE (PE1 in Figure 1), the
PE needs to establish suitable Path state and forward the Path
message on to the egress PE (PE2 in Figure 1). In the following
paragraphs we described the steps taken by the ingress PE.
The Path message is addressed to the eventual destination (the
receiver at the remote customer site) and carries the IP Router Alert
option, in accordance with [RFC2205]. The ingress PE must recognize
the router alert, intercept these messages and process them as RSVP
signalling messages.
K.Kumaki, et al. [Page 7]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
The details of operation at the ingress PE are as follows. When the
ingress PE receives a Path message from CE that is addressed to the
receiver, the VRF that is associated with the incoming interface is
identified, just as for normal data path operations. The tunnel end
point address of the receiver is looked up in the appropriate VRF,
and the BGP Next-Hop for that tunnel end point address is identified.
That next-hop is the egress PE. A new LSP_TUNNEL_VPN-IPv4/VPN-IPv6
SESSION Object is constructed, containing the Route Distinguisher
(RD) that is part of the VPN-IPv4/VPN-IPv6 route prefix for this
tunnel end point address, and the IPv4/IPv6 tunnel end point address
from the original SESSION Object. In addition, a new LSP_TUNNEL_VPN-
IPv4/IPv6 SENDER_TEMPLATE Object is constructed, with the original
IPv4/IPv6 tunnel sender address from the incoming SENDER_TEMPLATE
plus the RD that is used by this PE to advertise that prefix for this
customer into the VPN. A new Path message will contain all the
objects from the original Path message, replacing the original
SESSION and SENDER_TEMPLATE objects with the new LSP_TUNNEL_VPN-
IPv4/VPN-IPv6 type objects. The Path message is sent without IP
Router Alert.
4.2.2 Path Message Processing at Egress PE
When a Path message arrives at the egress PE (PE2 in Figure 1), it is
addressed to the PE itself, and is handed to RSVP for processing.
The router extracts the RD and IPv4/IPv6 address from the
LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION Object, and determines the local
VRF context by finding a matching VPN-IPv4 prefix with the specified
RD that has been advertised by this router into BGP. The entire
incoming RSVP message, including the VRF information, is stored as
part of the Path state.
Now the RSVP module can construct a Path message which differs from
the Path it received in the following ways:
a. Its tunnel end point address is the IP address extracted from the
SESSION Object;
b. The SESSION and SENDER_TEMPLATE objects are converted back to
IPv4-type/IPv6-type by discarding the attached RD
c. The RSVP_HOP Object contains the IP address of the outgoing
interface of the egress PE and an LIH, as per normal RSVP
processing.
The router then sends the Path message on towards its tunnel end
point address over the interface identified above. This Path message
carries the IP Router-Alert option as required by [RFC2205].
K.Kumaki, et al. [Page 8]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
4.2.3 Resv Processing at Egress PE
When a receiver at the customer site originates a Resv message for
the session, normal RSVP procedures apply until the Resv, making its
way back towards the sender, arrives at the "egress" PE (it is
"egress" with respect to the direction of data flow, i.e. PE2 in
figure 1). On arriving at PE2, the SESSION and FILTER_SPEC objects
in the Resv, and the VRF in which the Resv was received, are used to
find the matching Path state stored previously.
The PE constructs a Resv message to send to the RSVP HOP stored in
the Path state, i.e., the ingress PE (PE1 in Figure 1). The LSP
TUNNEL IPv4/IPv6 SESSION Object is replaced with the same
LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION Object received in the Path. The
LSP TUNNEL IPv4/IPv6 FILTER_SPEC Object is replaced with a
LSP_TUNNEL_VPN-IPv4/VPN-IPv6 FILTER_SPEC Object, which copies the
VPN-IPv4/VPN-IPv6 address from the LSP TUNNEL SENDER_TEMPLATE
received in the matching Path message.
The Resv message MUST be addressed to the IP address contained within
the RSVP_HOP Object in the Path message.
4.2.4 Resv Processing at Ingress PE
Upon receiving a Resv message at the ingress PE (with respect to data
flow, i.e. PE1 in Figure 1), the PE determines the local VRF context
and associated Path state for this Resv by decoding the received
SESSION and FILTER_SPEC objects. It is now possible to generate a
Resv message to send to the appropriate CE. The Resv message sent to
the ingress CE will contain LSP TUNNEL IPv4/IPv6 SESSION and LSP
TUNNEL FILTER_SPEC objects, derived from the appropriate Path state.
5. Security Considerations
This document defines RSVP-TE extensions for BGP/MPLS IP-VPNs. Hence
the security of the RSVP-TE extensions relies on the security of
RSVP-TE extensions for LSP tunnels.
The security issues are described in the existing RSVP-TE extensions
for LSP tunnels. [RFC3209]
6. IANA Considerations
IANA will assign six new C-types under the existing Class.
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = TBA
K.Kumaki, et al. [Page 9]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = TBA
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
7.2 Informative References
[E2E-RSVP-TE] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for
supporting Customer RSVP and RSVP-TE over a BGP/MPLS
IP-VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts (Work in
Progress), July 2009.
[RSVP-L3VPN] Davie, B., Faucheur, F. and Narayanan, A., "Support for
RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn
(Work in Progress), May 2009.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and
Jamin, S., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and
F. Le Faucheur, "BGP-MPLS IP Virtual Private Network
(VPN) Extension for IPv6 VPN", RFC 4659,
September 2006.
8. Acknowledgments
The author would like to express thanks to Makoto Nakamura for his
helpful and useful comments and feedback.
9. Author's Addresses
Kenji Kumaki (Editor)
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: ke-kumaki@kddi.com
K.Kumaki, et al. [Page 10]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
Tomoki Murai (Editor)
FURUKAWA NETWORK SOLUTION CORP.
5-1-9, HIGASHI-YAWATA, HIRATSUKA
Kanagawa 254-0016, JAPAN
Email: murai@fnsc.co.jp
Tomohiro Yamagata
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Email: to-yamagata@kddi.com
Chikara Sasaki
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino
Saitama 356-8502, JAPAN
Email: ch-sasaki@kddilabs.jp
Intellectual Property Statement
The IETF Trust 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 any IETF 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.
Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
K.Kumaki, et al. [Page 11]
draft-kumaki-murai-ccamp-rsvp-te-l3vpn-01 October 2009
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
K.Kumaki, et al. [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 03:27:54 |