One document matched: draft-ohta-mpls-label-value-03.txt-11670.txt
Differences from 03.txt-02.txt
H. Ohta
Internet Draft NTT
Document: draft-ohta-mpls-label-value-03.txt
Expires: March 2003 September 2002
Assignment of the 'OAM Alert Label' for
MPLS Operation and Maintenance (OAM) functions
Status of this Memo
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.
This document requests IANA to allocate a label value.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is subject to
all provisions of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the assignment of one of the reserved label
values defined in RFC 3032 (MPLS label stack encoding) to the 'OAM
Alert Label' that is used by user-plane MPLS Operation and
Maintenance (OAM) functions for identification of MPLS OAM packets.
Ohta Informational - Expires March 2003 1
Assignment of the "OAM Alert Label" Sept. 2002
for MPLS Operation and Maintenance (OAM) functions
1. Introduction
This document describes the assignment of one of the reserved label
values defined in RFC 3032 (MPLS label stack encoding[2]) to the 'OAM
Alert Label' that is used by user-plane MPLS Operation and
Maintenance (OAM) functions for identification of MPLS OAM packets as
described in the ITU-T draft Recommendation Y.1711[1] (on MPLS OAM
functions).
2. OAM functions
MPLS OAM (Operation and Maintenance) functions provide necessary
tools for network operators to operate and maintain the networks.
MPLS OAM functionality is required at the MPLS layer, and more
specifically at each MPLS level, independent of OAM functionality
provided by the lower layers (SONET/SDH, etc.). The objectives of
the OAM functions include the following:
- Defect and failure detection:
Defect/failures affecting the transport of user information are
detected by continuous or periodic checking. As a result,
maintenance event information or appropriate alarms will be
produced.
- Reporting the defect/failure information:
Defect information is given to other management entities (e.g.
Operation Support System) in order to provide the appropriate
indications to the maintenance staff for maintaining the Quality
of Service (QoS) level offered to customers.
- Defect/failure localization:
Determination by internal or external test systems of a failed
entity is performed if defect information is insufficient.
- Performance monitoring:
Performance (packet losses, transfer delay, bit errors, etc.) of
the user information transport is measured in order to estimate
the transport integrity.
3. OAM Packet Identification
The user-plane MPLS OAM mechanisms as described in the ITU-T draft
Recommendation Y.1711[1] uses a special label called 'OAM Alert
Label' to differentiate OAM packets from the normal user packets. One
of the reserved label values defined in RFC 3032 (MPLS label stack
encoding[2]) is assigned to 'OAM Alert Label'. A value of 14 is used
for this purpose.
Ohta Informational - Expires March 2003 2
Assignment of the "OAM Alert Label" Sept. 2002
for MPLS Operation and Maintenance (OAM) functions
4. MPLS OAM work in ITU-T SG13
ITU-T Study Group 13, Question 3/13 is progressing work on user-plane
MPLS OAM and has produced the following documents:
(1) Recommendation Y.1710 (Requirements for OAM functionality for
MPLS networks)[3]
(2) Draft Corrigendum 1 to Recommendation Y.1710[4], completed last
call (July 2002) and is targeted for approval (Nov. 2002)
(3) Draft Recommendation Y.1711 (OAM mechanisms for MPLS
networks)[1], completed last call (July 2002) and is targeted
for approval (Nov. 2002)
(4) Draft Recommendation Y.1720 (Protection switching for MPLS
networks)[6] which relies on OAM mechanisms in Y.1711, targeted
for last call as of Nov. 2002 (following approval of Y.1711).
5. Considerations on penultimate hop popping (PHP)
In response to concerns raised during IETF meetings and in related
discussions, this section provides an explanation on how MPLS OAM
functions defined in ITU-T Recommendation Y.1711[1] are applied to
MPLS networks where PHP is in effect.
5.1 Scope of ITU-T Recommendation Y.1711
The scope of ITU-T Recommendation Y.1711 includes application to both
non-PHP and PHP cases as quoted below[1].
"1 Scope
This Recommendation provides mechanisms for user-plane OAM (Operation
and Maintenance) functionality in MPLS networks according to the
requirements and principles given in Recommendation Y.1710. OAM
functions specified in this Recommendation can be applied to both
non-PHP and PHP cases unless otherwise stated. The current version
of this recommendation is designed primarily to support point-to-
point and multipoint-to-point explicit routed LSPs (ER-LSPs)."
5.2 Applicability of MPLS OAM to PHP
There are two cases where PHP is used:
Case 1: The ultimate node is an MPLS LSR, and implements both MPLS
control-plane and data-plane, but is not able to do 2 lookups at line
Ohta Informational - Expires March 2003 3
Assignment of the "OAM Alert Label" Sept. 2002
for MPLS Operation and Maintenance (OAM) functions
rate. So it asks the penultimate node to pop the top label (rather
than swapping it), using the MPLS reserved label 3 (implicit null
label) as per defined in RFC3032[2].
Case 2: The ultimate node has no MPLS label look up and processing
capability and does not recognize labeled packets. This node asks for
PHP, using the MPLS reserved label 3 (implicit null label) as per
defined in RFC3032[2].
Currently, MPLS OAM functions defined in ITU-T Recommendation
Y.1711[1] can be applied to the case 1 only. Next subsection
describes the node behavior in case 1. Application to case 2 is for
further study. Also, application to carrier supporting carrier
scenarios is for future study.
5.3 Node behavior when OAM functions are activated
Where the ultimate LSR is an MPLS LSR and PHP is in effect, the
penultimate LSR pops the top label and forwards the OAM packet (with
the OAM label and OAM payload intact) to the ultimate LSR [5].
- If the ultimate LSR supports MPLS OAM, it understands that received
packet with OAM label on top is an OAM packet knowing original top
label has been removed by the penultimate LSR. It also knows the
ingress LSR which originated the MPLS OAM packet from the TTSI
(Trail Termination Source Identifier) value of the received MPLS
OAM packet. TTSI is a unique identifier for ingress LSR which is
contained in MPLS OAM packets (see ITU-T Recommendation Y.1711[1]).
- If the ultimate LSR does not support MPLS OAM, the OAM packet is
discarded as per section 3.18 of RFC3031[5].
6. IANA considerations
It is requested that IANA consider if the use of the MPLS reserved
label value of 14 as the 'OAM Alert Label' is acceptable. If it is
acceptable, it is requested that this value is officially assigned as
the 'OAM Alert Label'. Should the said value not be acceptable by
IANA, ITU-T SG13 is ready to accept another reserved label value (as
per IANA's recommendation). ITU-T SG13 appreciates if IANA will
advise the author of any problem with the use of the value of 14, and
if necessary recommends an alternative reserved label value no later
than October 25, 2002.
Ohta Informational - Expires March 2003 4
Assignment of the "OAM Alert Label" Sept. 2002
for MPLS Operation and Maintenance (OAM) functions
7. Security considerations
This document does not raise any security issues that are not already
present in either the MPLS architecture or in the architecture of the
network layer protocol contained within the encapsulation.
OAM functions could enhance the security of MPLS networks. For
example, Connectivity Verification (CV) function defined in ITU-T
Recommendation Y.1711[1] can detect mis-connections, and therefore
can prevent customers' traffic to be exposed to other customers.
8. Acknowledgement
The author wishes to thank Shahram Davari with PMC-Sierra, Neil
Harrison with British Telecom, Monique Morrow, Thomas D. Nadeau, Hari
Rakotoranto and Chip Sharp with Cisco Systems and Mina Azad, Khalid
Ahmad and David Allan with Nortel Networks for their valuable
contributions and discussions.
9. Normative references
[1] ITU-T Draft Recommendation Y.1711, "OAM mechanism for MPLS
networks", Chitose, Japan, July 2002
[2] IETF, RFC 3032, "MPLS label stack encoding", Category: Standards
Track, January 2001.
[3] ITU-T recommendation Y.1710, "Requirements for OAM functionality
for MPLS networks" Caracas, Venezuela, May 2001
[4] ITU-T Draft Corrigendum 1 to Recommendation Y.1710, Chitose,
Japan, July 2002.
[5] IETF, RFC 3031, " Multiprotocol Label Switching Architecture",
Category: Standards Track, January 2001.
10. Informative reference
[6] ITU-T Draft Recommendation Y.1720, "Protection switching for MPLS
networks", Chitose, Japan, July 2002.
Ohta Informational - Expires March 2003 5
Assignment of the "OAM Alert Label" Sept. 2002
for MPLS Operation and Maintenance (OAM) functions
11. Author's Address
Hiroshi OHTA
NTT
3-9-11 Midori-Cho, Musashino-Shi
Tokyo 180-8585 Japan
Tel: +81 422 59 3617
Fax: +81 422 59 3787
Email: ohta.hiroshi@lab.ntt.co.jp
Ohta Informational - Expires March 2003 6
| PAFTECH AB 2003-2026 | 2026-04-23 21:35:28 |