Network Working Group Sami Boutros (Ed.)
Internet Draft Siva Sivabalan(Ed.)
Intended status: Standards Track George Swallow
Expires: September 2009 David Ward
Stewart Bryant
Cisco Systems, Inc.
March 9, 2009
Performance Monitoring of MPLS Transport Profile LSP
draft-boutros-mpls-tp-performance-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
This Internet-Draft will expire on September 9, 2009.
Abstract
This document specifies an extension to MPLS Operation,
Administration, and Maintenance (OAM) for monitoring the performance
of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) with
respect to packet loss and unidirectional delay/jitter.
Table of Contents
Boutros Expires September 9, 2009 [Page 1]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
1. Introduction...................................................2
2. Terminology....................................................4
3. MPLS-TP Performance Monitor Mechanism..........................5
4. MPLS-OAM Performance Message...................................5
4.1. In-band Message Identification............................5
4.2. Out-of-band Message Identification........................6
4.3. MPLS-OAM Performance control Message Format...............6
4.4. Performance Request TLV...................................8
4.5. Packet Loss Reporting TLV.................................9
4.6. Performance Removal.......................................9
4.7. MPLS-OAM PF Packet........................................9
4.8. Monitoring regular PW packets............................10
4.9. Network Management System................................10
5. Operation.....................................................11
6. Security Considerations.......................................12
7. IANA Considerations...........................................12
8. References....................................................12
8.1. Normative References.....................................12
8.2. Informative References...................................13
Author's Addresses...............................................14
Full Copyright Statement.........................................14
Intellectual Property Statement..................................15
1. Introduction
In traditional transport networks, circuits such as T1 lines are
provisioned on multiple switches, and service providers should be
able to monitor the performance of such circuits for management
purpose. For example, when performance of a primary circuit degrades
backup circuit may be activated. An MPLS-TP bidirectional LSPs
emulate the traditional transport circuits and hence should provide
the same performance measurement capability. In this document, an
MPLS-TP LSP means either an MPLS transport LSP or an MPLS Pseudowire
(PW).
This document specifies an MPLS-TP LSP performance monitoring scheme
that is based on two new types of MPLS-OAM packets called "MPLS-OAM
Performance Control(PC)" and "MPLS-OAM Performance Flow(PF)". These
packets are sent at a rate that is acceptable to both sender and
receiver. The MPLS-OAM PC packets are used to setup an MPLS-TP LSP
for performance monitoring, and the MPLS-OAM PF packets are used as
the probes for collecting performance data.
Performance can be monitored using one of the two following modes:
Boutros Expires September 9, 2009 [Page 2]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
On-Demand: An MPLS-TP LSP's performance is monitored only based on
operator request, i.e., performance is not monitored automatically
as soon as the LSP becomes operational.
Continuous: In this mode, it is assumed that an MPLS-TP LSP is
configured for continuous performance monitoring. Also, the
relevant configuration can be applied to and removed from an MPLS-
TP LSP at any time during the life of the LSP. When configured for
continuous performance monitoring, an MPLS-TP LSP's performance is
continuously monitored as soon as it becomes operational.
The following features are common to both the on-demand and the
continuous modes:
1. The LSP can be optionally locked for data traffic.
2. MPLS-OAM PC and PF packets can be consumed by either a Maintenance
Intermediate Point (MIP) or a Maintenance End Point (MEP).
3. MPLS-OAM PC and PF packets are intercepted at any MIP based on
MPLS TTL expiry, and are intercepted at MEP simply because it is
the egress LSR of the LSP (i.e., regardless of the TTL value).
4. More than one MPLS-OAM performance flows can be maintained
simultaneously from a MEP to any MIP or the other MEP.
5. The transmission rate of MPLS-OAM PF packets MUST be acceptable to
both the sender and the receiver, otherwise transmission of such
packets MUST NOT begin. The rate is negotiated via MPLS-OAM PC
packets.
6. An MPLS OAM PF packets contains sequence number and time-stamp to
measure packet loss and unidirectional delay/jitter.
In the continuous mode, the MEP at which performance is monitored is
configured to send MPLS-OAM PF packets continuously to different MIPs
and/or the other MEP. The configuration specifies:
. Rate at which the MPLS-OAM PF packets are sent.
. Addresses of MIPs/MEP to which the MPLS-OAM PF packets are
destined.
. Whether or not performance is monitored in both directions of the
MPLS-TP LSP.
Boutros Expires September 9, 2009 [Page 3]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
. Rate at which the number of lost MPLS-OAM PF packets should be
reported to the sender MEP.
The proposed mechanism is based on a set of new TLVs which can be
transported using one of the following methods:
1. Using in-band MPLS OAM messages which are forwarded as MPLS
packets (non-IP based).
2. Using in-band LSP-Ping extensions defined in [3] where IP/UDP
packets are used (IP-based). The LSP-Ping messages are sent
using the codepoint defined in [2].
Method (1) and (2) are referred to as "Non-IP option" and "LSP-Ping
option" respectively in the rest of the document.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [1].
2. Terminology
ACH: Associated Channel Header
LSR: Label Switching Router
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile
MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit
NMS: Network Management System
PC: Performance Control
PF: Performance Flow
Boutros Expires September 9, 2009 [Page 4]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
PM: Performance Monitoring
TLV: Type Length Value
TTL: Time To Live
3. MPLS-TP Performance Monitor Mechanism
For the Non-IP option, the proposed mechanism uses two new code
points in the Associated Channel Header (ACH) described in [6]. The
LSP-Ping option is in compliance to the specifications [2],[3], and
[7].
The proposed mechanism requires a set of new TLVs called Performance
Request TLV, Performance Loss Report TLV.
In addition, the proposed mechanism uses the Address and LSPI TLVs
defined in [5]. Moreover, it can also be used in conjunction with the
data-locking mechanism defined in [4].
The new TLVs are described below.
4. MPLS-OAM Performance Message
4.1. In-band Message Identification
In the in-band option, under MPLS label stack of the MPLS-TP LSP, the
ACH with "MPLS-TP Performance Control" code point indicates that the
message is an MPLS OAM Performance Control (PC) message. The ACH with
code point "MPLS-TP Performance Flow" indicates that the message is
an MPLS OAM Performance Flow (PF) message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|Flags | 0xHH MPLS-TP Performance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP Performance Control
The first nibble (0001b) indicates the ACH. The version and the
reserved values are both set to 0 as specified in [1]. MPLS-TP
Performance control and performance flow code points = 0xHH and 0xhh.
[HH and hh to be assigned by IANA from the PW Associated Channel Type
registry.]
Boutros Expires September 9, 2009 [Page 5]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
4.2. Out-of-band Message Identification
[To be added]
4.3. MPLS-OAM Performance control Message Format
The format of an MPLS-OAM Performance control Message is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Operation | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code | Cause Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV's |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP OAM Message Format
Version
The Version Number is currently 1.
Message Type
Four message types are defined as shown below.
Message Type Description
------------ -------------
0x1 Performance Request
0x2 Performance Report
0x3 Performance Removal
0x4 Performance Response
Operation
Boutros Expires September 9, 2009 [Page 6]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
Two operations are defined as shown below. In the unidirectional
mode, the receiver MIP or MEP does not have to maintain a PM flow
towards the sender MEP. But, in the bidirectional mode, the receiver
MIP or MEP MUST maintain a PM flow towards the sender MEP.
Operation Description
--------- -------------
0x0 Unidirectional
0x1 Bidirectional
Sender's Handle
The Sender's Handle is filled in by the sender. There are no
semantics associated with this handle.
Message Length
The total length of any included TLVs.
Message ID
The Message ID is set by the sender and is incremented everytime the
sender sends a new message. The receiver MUST include the Message ID
in the response. This way, the sender can correlate a reply with the
corresponding request.
Return code
Value Meaning
----- -------
0 Informational
1 Success
2 Failure
Cause code
Value Meaning
----- -------
1 Fail to match MPLS-TP LSP ID.
2 Malformed performance message received
3 One or more of the TLVs is/are unknown
4 Authentication failed
5 Specified PF Packet Rate cannot be supported
6 Specified Packet Loss Report Rate cannot be supported
Boutros Expires September 9, 2009 [Page 7]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
Note that the MPLS-TP LSP whose performance is to be monitored is
identified by the LSP ID TLV as defined in [5] in the MPLS-OAM
performance message.
MPLS-TP performance control message may include authentication TLV
defined in [4].
4.4. Performance Request TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = TBD | length = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Performance Flow Packet Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Loss Report Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Performance Request TLV
When a MEP wants to monitor performance on an MPLS-TP, it sends an
MPLS-OAM PC packet with Performance Request TLV. The Performance
Request message can be intercepted by either a MIP (due to TTL
expiry) or a MEP (simply because it is the egress LSR).
Performance Flow Packet Rate (in packets per second) specifies the
maximum rate at which MPLS-OAM PF packets can be sent.
Packet loss Report Rate specifies the maximum rate at which the loss
of MPLS-OAM PF packets can be reported to the sender MEP.
The receiver MIP or MEP MUST send either an ACK or NAK response to
the sender MEP using an MPLS OAM performance response message. An ACK
response is sent if the receiver can support the specified rates.
Otherwise, a NAK response is sent. Until an ACK response is received,
the sender MEP MUST NOT assume that the MPLS-TP LSP is ready for
performance monitoring.
If multiple Performance Request TLVs are present, only the first TLV
is taken into consideration.
Boutros Expires September 9, 2009 [Page 8]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
4.5. Packet Loss Reporting TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = TBD | length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Number of Packets Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Packet Loss Report TLV
Performance monitor report MPLS-OAM Messages will be sent at the rate
that does not exceed the maximum packet loss reporting rate specified
in the MPLS-OAM Performance Request TLV.
This TLV includes the number of lost MPLS-OAM PF packets as well as
the total number of MPLS-OAM PF flow packets that it must have
received from the sender. The receiver figures out the latter using
the sequence number in the MPLS-OAM PF packets (described below).
4.6. Performance Removal
When performance monitor mode operation of an MPLS-TP LSP is no
longer required, the MEP that previously sent the MPLS OAM
Performance request message sends another MPLS OAM performance
removal message.
The receiver MEP or MIP MUST send either an ACK or NAK response to
the sender MEP using an MPLS OAM performance response message. An ACK
response is sent if the MPLS-TP LSP is already monitoring
performance. Otherwise, a NAK response is sent.
4.7. MPLS-OAM PF Packet
When the performance of MPLS-TP LSP is monitored, MPLS-OAM PF packets
are sent from the sender MEP to the MEP/MIP end of the flow. A PF
packet contains a sequence number and a time-stamp using which the
receiver can calculate packet loss and one-way delay/jitter.
Boutros Expires September 9, 2009 [Page 9]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label stack |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label with EOS bit set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|Reserved |0xHH (MPLS-TP Performance Flow)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MPLS-OAM PF Packet
4.8. Monitoring regular PW packets
When the performance of PW is monitored, in continuous mode, regular
PW data packets can be used to monitor performance. PW packets in the
presence of CW contain a sequence number that can be used to measure
packets loss.
Data traffic is sent over an MPLS-TP PW using the format shown
below:-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN LSP label stack (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label with EOS set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.9. Network Management System
An operator should be able to provision any given LSR to:
1. Lock/Unlock any MPLS-TP LSP.
2. Send MPLS OAM packets from a MEP and notify NMS when MPLS OAM
response arrives.
Boutros Expires September 9, 2009 [Page 10]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
When NMS is used to provision any of the above the functionality, the
corresponding MPLS OAM message is not used.
5. Operation
Consider an MPLS-TP LSP LSR-1 <--> LSR-2 <--> LSR-3 <--> LSR-4 <-->
LSR-5. LSR-1 and LSR-5 are ingress and egress LSR for the respective
direction, and LSR-1 and LSR-5 act as MEPs and LSR-2, LSR-3 and LSR-5
acts as a MIPs.
Assume that the objective is to evaluate the performance of the
segment between LSR-1 and LSR-2 at LSR-1. Thus, LSR-2 is the
destination for the MPLS-OAM PM packets.
1- LSR-1 sends an optional Lock Request MPLS-OAM message to LSR-5
(egress LSR) to take the MPLS-TP LSP out of service
2- LSR-5 takes the MPLS-TP LSP out of service from data-plane and
sends an ACK MPLS-OAM message back to LSR-1
3- LSR-1 sends a PM Request MPLS-OAM message to LSR-2 containing its
source address the MPLS-TP LSP ID, and destination address of
LSR-2, maximum rate at which PF packets are to be sent, maximum
packet loss report rate (back to LSR-1), and an indication as to
whether or not LSR-2 also needs to send MPLS-OAM PM packets.
4- LSR-2 verifies the LSP ID, and the destination address and sends
a performance response MPLS-OAM message with return code
1(success) back to LSR-1 if it can handle the specified PM packet
transmission and loss reporting rate, otherwise LSR-2 sends the
performance response MPLS-OAM message with return code 2(failure)
back to LSR-1 with the following cause codes:
1. if destination address or LSP-ID cannot be matched, it sends
a response with cause code 1.
2. if the message is malformed, it sends a response with the
cause code 2.
3. if any of the TLV is not known, it sends a response with
cause code 3. It may also include the unknown TLVs.
4. if message authentication fails, it sends a response with
the cause code 4.
5. if the specified PF packet rate cannot be handled, it sends
a response with cause code 5.
Boutros Expires September 9, 2009 [Page 11]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
6. if the specified packet loss report rate cannot be
supported, it sends a response with cause code 6.
Note that MPLS TTL value is set to 255 in the response message.
After receiving the ACK from LSR-2 for the MPLS-OAM PM request,
MPLS-OAM PF packets are transmitted on the MPLS-TP LSP.
Both LSR-1 and LSR-2 keep a count of the lost MPLS-OAM PF packets.
The receiver LSR computes the number of lost MPLS-OAM PF flow
packets using the sequence number. Note that the sequence number
equals the total number of packets that must have received in the
absence of any packet loss.
The receiver periodically send the number of lost MPLS-OAM PF
packets as well as the total number of MPLS-OAM PF packets that it
must have received to the sender.
Removal of PM mode (only for on-demand mode)
1- LSR-1 sends an MPLS-OAM message to LSR-2 in order to stop
operating the MPLS-TP LSP in Performance Management mode.
2- LSR-2 sends its latest Packet Loss Report to LSR-1 via an MPLS-OAM
message.
3- LSR-1 sends an Unlock Request MPLS-OAM message to LSR-5
4- LSR-5 puts the MPLS-TP LSP back in service and sends an ACK MPLS-
OAM message back to LSR-1.
6. Security Considerations
The security considerations for the authentication TLV need further
study.
7. IANA Considerations
To be added.
8. References
8.1. Normative References
[1] Bradner. S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997.
Boutros Expires September 9, 2009 [Page 12]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
[2] T. Nadeau, et. al, "Pseudowire Virtual Circuit Connectivity
Verification (VCCV): A Control Channel for Pseudowires ", RFC
5085, December 2007.
[3] K. Kompella, G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[4] S. Boutros, et. al., "Operating MPLS Transport Profile LSP in
Loopback Mode", draft-boutros-mpls-tp-loopback-01.txt, Work in
Progress, December 2008.
8.2. Informative References
[5] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-
bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009.
[6] M. Bocci, et. al., "MPLS Generic Associated Channel", draft-
ietf-mpls-tp-gach-gal-02.txt, work in progress, January 6,
2009.
[7] Nabil Bitar, et. al, "Requirements for Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3) ", RFC5254, October 2008.
Boutros Expires September 9, 2009 [Page 13]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
Author's Addresses
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: sboutros@cisco.com
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
Email: msiva@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MASSACHUSETTS 01719
United States
Email: swallow@cisco.com
David Ward
Cisco Systems, Inc.
3750 Cisco Way
San Jose, California 95134
USA
Email: wardd@cisco.com
Stewart Bryant
Cisco Systems, Inc.
250, Longwater, Green Park,
Reading RG2 6GB, UK
UK
Email: stbryant@cisco.com
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
Boutros Expires September 9, 2009 [Page 14]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
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.
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.
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.
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
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.
Boutros Expires September 9, 2009 [Page 15]
Internet-Draft draft-boutros-mpls-tp-performance-01.txt March 2009
For the avoidance of doubt, each Contributor to the UETF 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Boutros Expires September 9, 2009 [Page 16]