MPLS Working Group L. Dunbar
Internet Draft Huawei
Intended status: Standard Track N. So
Expires: February 2011 Verizon
P. Niger, Y. Le Goff
France Telecom
August 13, 2010
Detecting MPLS Path Impairment using MPLS-Ping
draft-dunbar-so-mpls-detect-impair-mplsping-02.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 February 13, 2009.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Dunbar Expires February 13, 2011 [Page 1]
Internet-Draft Path Condition Marking using BFD August 2010
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract
The MPLS-Ping is for detecting data path failure. This draft suggests
an extension to MPLS-Ping so that transit LSR can indicate the
downstream link impairment condition to the source LSR.
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 RFC-2119 0.
Table of Contents
1. Motivation..........................................2
2. MPLS-Ping extension for path condition impairment indication..3
2.1. Downstream Link Condition sub-TLV...................4
2.2. Link Condition Request in Echo Request...............5
2.3. Receiving Echo Request with a Path Condition Request flag set
..................................................6
3. Receiving Path Condition Impairment Notification...........6
4. Manageability Considerations...........................7
5. Security Considerations...............................7
6. IANA Considerations...................................7
7. Acknowledgments......................................7
8. References..........................................7
8.1. Normative References..............................7
Authors' Addresses......................................8
Intellectual Property Statement...........................8
Disclaimer of Validity...................................9
1. Motivation
MPLS-Ping [MPLS-Ping] can be used to detect faults along the LSP
path. One of the faults detected by MPLS-Ping is downstream link
failure, i.e. link connectivity being down. In some network
environment, source node also needs to know the condition of the link
on which the LSPs are carried even though the link connectivity is
up. That way the source LSR can perform needed functions, such as
enforcing admission control, re-signal and/or re-compute the LSP
Dunbar, So Expires February 13, 2011 [Page 2]
Internet-Draft Path Condition Marking using BFD August 2010
path, or generate more stringent performance monitoring at shorter
interval, and etc.
A common example for the link condition change is the bandwidth
fluctuation in Mobile Backhaul network, where Microwave transport is
widely deployed. Most Microwave transport nodes adjust its bandwidth
based on the weather. Even though there is RSVP-TE for individual
links to advertise its available bandwidth in the routing domain,
end-to-end bandwidth change may not be possible in some Mobile
Backhaul environment, because there may be multiple routing domains
from base stations to MSO. If Source Nodes, i.e. LTE's eNodeB or
MSO's RNC, are aware of the bandwidth change, they can adjust
services accordingly, request other base stations to accept new
calls, or trigger a new Performance Monitoring scheme to track the
condition more closely.
In another application, source LSRs may want to be aware of the
congestion along the LSP path, so that proper actions can be taken.
MPLS-ECN (RFC 5129) specifies a mechanism for transit nodes to mark
EXP bits when congestion happens. However, many deployed MPLS
networks already use EXP bits to mark packet priorities, making MPLS-
ECN (RFC 5129) mechanism un-usable for the purpose of LSP change
indication.
In a third application, source LSRs may want to be aware of
significant performance degradation on the downstream links along the
LSP path. The performance degradation can be increased latency
and/or increased delay variation. Those performance degradations may
be induced by the physical layer protection scheme, such as link
switching from active side of the ring to protect side of the ring,
or it may be induced by transmission media degradation.
In a forth application, source LSRs may want to be aware of transport
media change on the downstream links along the LSP path. For
example, the link can be a fiber protected by microwave, and the
source router may be carrying an application that cannot use
microwave due to security concerns.
This draft suggests adding a new sub-TLV to the MPLS Ping Echo Reply
for the transit LSR to indicate the downstream link condition changes
to source routers.
2. MPLS-Ping extension for path condition impairment indication
[MPLS-Ping] specified that replying router for MPLS Ping should
include one Downstream Mapping for each interface, over which this
FEC could be forwarded, in the Echo Reply. [MPLS-Ping-Enhanced] has
Dunbar, So Expires February 13, 2011 [Page 3]
Internet-Draft Path Condition Marking using BFD August 2010
introduced 3 types of sub-TLV to the Downstream Detailed Mapping,
Multipath data, Label stack, and FEC Stack change.
This draft suggests adding a new sub-TLV "Downstream Link Condition"
to indicate the condition of the downstream link of the corresponding
interface. The "Downstream Path Condition" could be bandwidth being
reduced, the interface being congested, etc.
Sub-Type Value Field
-------- --------
TBD Multipath data (specified by [MPLS-Ping-Enhanced])
TBD Label stack (specified by [MPLS-Ping-Enhanced])
TBD FEC Stack change (specified by [MPLS-Ping-Enhanced])
TBD Downstream Link Condition (new)
2.1. Downstream Link Condition sub-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 | Length |ImpairmentType | SeverityLevel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Impairment Type field can take one of the following values:
Value Meaning
-------- --------
1 port towards downstream LSR is congested
2 Bandwidth of the link towards downstream LSR is reduced
3 performance of the link towards downstream LSR is reduced
4 transport media of the link towards downstream LSR has
been changed
The Severity Level field is a value indicating the severity of the
impairment. Network operator can set the Severity Level for
anticipated conditions and configure the proper actions at the source
node upon receiving the Echo Reply. For example, Severity Level 0 can
represent full bandwidth, 1 represents the next bandwidth level, and
6 represents the least bandwidth. For microwave transport link within
MPLS based Mobile Backhaul network, the Adaptive Modulation usually
has several levels of adjusted bandwidth, which can be used as the
basis for setting the Severity Level.
Dunbar, So Expires February 13, 2011 [Page 4]
Internet-Draft Path Condition Marking using BFD August 2010
2.2. Link Condition Request in Echo Request
If a source LSR of a LSP cannot do anything when the LSP path is
impaired, then there is no point for the transit LSR to send any link
condition in the Echo Reply to the sender. Therefore, it is necessary
for the sender to indicate if it desires to receive the Downstream
Link Condition status in the Echo Reply. This draft suggests using
one reserved bit of DS flags in the Echo Request for the source node
to indicate if it desires to receive the impairment condition of the
downstream link on a transit LSR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DS Flags
RFC4379 already defines I bit and N bit out of the octet DS Flags.
This draft suggests adding a new bit C for source LSR to indicate
if it desires to have the link impairment condition to be reported
by transit LSR in the Echo Reply.
The DS flags field is a bit vector with the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
Dunbar, So Expires February 13, 2011 [Page 5]
Internet-Draft Path Condition Marking using BFD August 2010
|Rsvd(MBZ)|C|I|N|
+-+-+-+-+-+-+-+-+
I and N flags are already specified by RFC 4379. The C flag is
defined as follow:
Flag Name and Meaning
----- ----------------
C Source LSR desires to know the downstream link condition
When this flag is set (C = 1), it indicates that the replying
router SHOULD include the downstream link condition sub-TLV in the
echo reply message. When this flag is not set (C=0), it indicates
that the source LSR doesn't need downstream path condition
information, so replying router SHOULD NOT include the downstream
link condition sub-TLV in the echo reply.
2.3. Receiving Echo Request with a Path Condition Request flag set
If the DS flags' C is set, the receiving LSRs HAVE TO construct the
Downstream Link Condition sub-TLV and insert it into the Echo
Reply.
3. Receiving Path Condition Impairment Notification
Though it is out of the scope of this draft on what Source LSR will
do upon receiving the Path Condition in the Echo Reply, here are some
examples of possible actions Source LSR could do:
trigger more stringent performance monitoring in shorter
interval to measure the quality of the path
re-adjust load balancing among the multiple paths from Source
LSR to the Destination LSR
Re-signal LSP to alternative path
activate the secondary/protection path
adjust admission rate (in the case of LTE eNodeB)
Notify adjacent client device via E-LMI, IEEE802.3ah, or simple
flow control.
Dunbar, So Expires February 13, 2011 [Page 6]
Internet-Draft Path Condition Marking using BFD August 2010
4. Manageability Considerations
This document does not add additional manageability considerations.
5. Security Considerations
This document has no additional requirement for a change to the
security models of MPLS-Ping and MPLS-Ping-Enhanced.
6. IANA Considerations
A future revision of this document will present requests to IANA for
codepoint allocation.
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
8. References
8.1. Normative References
[ECN] B. Davie, et. al., "Explicit Congestion Marking in MPLS",
RFC 5129, Jan. 2008.
[MPLS-PING] K. Kompella, et. al., "Detecting MPLS Data Plane
Failures", RFC 4379, February 2006.
[BFD-MPLS] Aggarwal, R., "draft-ietf-bfd-mpls-07.txt", work in
progress.
[LSP-Ping-Enhanced] N. Bahadur, et. al.,"Mechanism for performing
LSP-Ping over MPLS tunnels", "draft-ietf-mpls-lsp-ping-
enhanced-dsmap-04", work in progress.
Dunbar, So Expires February 13, 2011 [Page 7]
Internet-Draft Path Condition Marking using BFD August 2010
Authors' Addresses
Linda Dunbar (Ed.)
Huawei Technologies
1700 Alma Drive, Suite 500
Plano, TX 75075, USA
Phone: (972) 543 5849
Email: ldunbar@huawei.com
Ning So (Ed.)
Enterprise Data Network and Traffic Planning
2400 N. Glenville Dr.
Richardson, TX 75082, USA
Phone: (972) 729 7905
Email: ning.so@verizonbusiness.com
Philippe Niger
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: philippe.niger@orange-ftgroup.com
Yannick Le Goff
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: yannick1.legoff@orange-ftgroup.com
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
Dunbar, So Expires February 13, 2011 [Page 8]
Internet-Draft Path Condition Marking using BFD August 2010
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dunbar, So Expires February 13, 2011 [Page 9]