Network Working Group L. Dunbar
Internet Draft Huawei
N. So
Verizon
Intended status: Standard Track
Expires: July 2010
January 19, 2010
Path Condition Change Marking using BFD
draft-dunbar-bfd-path-condition-change-marking-00.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 July 19, 2010.
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
Dunbar, So Expires July 19, 2010 [Page 1]
Internet-Draft Path Condition Marking using BFD January 2010
(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
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract
There are times that an LSP source node needs to know change(s) has
occurred along the originally established LSP path. This is
especially true in the Mobile Backhaul environment where microwave
transport is widely deployed. The bandwidth provided by the microwave
transport can change with weather. The source LSR, e.g. LTE's eNodeB,
needs to adjust its admission rate or shift more load to alternative
paths when the backhaul transport path condition is changed.
This draft describes a simple mechanism for transit LSRs to notify
Source LSR of the path condition changes.
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..................................................3
2. Analysis of potential methods................................3
3. BFD protocol extension for path condition impairment notification
...............................................................4
4. Path Condition Impairment Notification.......................6
5. Receiving Path Condition Impairment Notification.............7
6. Manageability Considerations.................................7
7. Security Considerations......................................8
8. IANA Considerations.........................................8
9. Acknowledgments.............................................8
10. References.................................................8
10.1. Normative References...................................8
10.2. Informative References.................................8
Authors' Addresses.............................................9
Intellectual Property Statement.................................9
Dunbar, So Expires July 19, 2010 [Page 2]
Internet-Draft Path Condition Marking using BFD January 2010
Disclaimer of Validity........................................10
1. Motivation
LSP's source node(s) can have multiple paths to the corresponding
destination node(s). Those paths can have different performance
behavior such as delay, delay variation, bandwidth, and so on. The
LSP(s)' can carry traffic with various Class of Services (CoS). Some
of the premium CoS require strict performance objectives to be met at
all time, so it is desirable to have LSP's source node(s) to be
notified if there is any condition change along the LSP path. That
way the source node(s), which is aware of the performance objectives,
can make the proper decision if an alternative path needs to be
established, or the admission rate needs to be changed for the
incoming traffic.
A common example for the LSP 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 to all the nodes in the
routing domain, RSVP-TE might not be possible in some Mobile Backhaul
environment where there might be multiple routing domains from base
stations to MSO. If Source Nodes, i.e. LTE's eNodeB, are aware of the
bandwidth change, they can adjust services accepted to the network,
request other base stations to accept new calls, or trigger (or
increase the frequency of) Performance Monitoring scheme.
In other applications, some source LSRs want to get notified when
there is congestion condition or port changes on the transit nodes,
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
priority, making it not possible to use MPLS-ECN (RFC 5129) mechanism
for the purpose of LSP change notification.
2. Analysis of potential methods
There is MPLS-ECN (RFC 5129) marking on the MPLS header's EXP field
when transit nodes encounter congestion. The problem with MPLS-ECN
(RFC 5129) is that many deployed MPLS networks already use EXP bits
to represent priority. Another issue with MPLS-ECN (RFC 5129) is that
the congestion marking doesn't occur until congestion happens. When a
transit link bandwidth is reduced, such as microwave transport link
bandwidth reduction due to weather, queues on the transit node can
Dunbar, So Expires July 19, 2010 [Page 3]
Internet-Draft Path Condition Marking using BFD January 2010
quickly build up. Even if MPLS-ECN (RFC 5129) scheme is used, the
queue on the transit node may already been overrun by the time the
egress node recognizing the congestion and notifies the source node.
When there is a hard event change on a transit LSR, such as bandwidth
reduction or port change, an alternative approach is for the transit
LSR to send a simple notification to the source node indicating the
change occurred. However, the transit nodes may not know the source
nodes of the LSPs (e.g. LDP LSPs). Although the transit LSR can get
the source LSR's IP address from the MPLS-Ping Request message, the
MPLS-Ping may not be triggered when there is condition change on the
LSP path.
Another alternative is to mark on the MPLS header to indicate the
hard impairment event occurred on the path. It is the similar
approach as the MPLS-ECN (RFC5129). However, there are no available
bits on the MPSL header for such marking.
3. BFD protocol extension for path condition impairment notification
When periodic BFD is enabled between a pair of LSRs (the Source and
the destination), the BFD frequency is based on a fixed interval,
usually in the magnitude of milliseconds. Since MPLS-BFD is intended
to traverse along the LSP path, a transit node has the information on
the port to the downstream LSR and is aware of the downstream link
status, including impairment status, such as bandwidth being reduced,
port being altered, or congested. Therefore, BFD is a good choice for
path condition impairment notification when BFD is enabled on the
LSP.
This draft suggests adding an optional Impairment section to the BFD
Control Frame:
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 |ImpairmentValue|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Routable IPV4 or IPV6 address of source LSR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a source LSR of a LSP cannot do anything when the LSP path is
impaired, then the source LSR SHOULD NOT include this optional
section in the BFD control frame. When the Impairment section is not
present in the BFD control frame, the transit LSR does not need to
mark the path condition change indication.
Dunbar, So Expires July 19, 2010 [Page 4]
Internet-Draft Path Condition Marking using BFD January 2010
If the Source LSR can do something when the normal LSP path is
impaired or altered, the Source LSR CAN include the optional
Impairment section in the BFD Control Frame. If the Impairment
section is attached, the transit LSR CAN do the following when
experiencing downstream link impairment:
The transit LSR SHOULD mark on the Impairment field of the
condition of downstream link, and/or
The transit LSR SHALL send a Path Condition Impairment
Notification (PCIN) back to the source LSR if it knows the
source LSR.
The Impairment Value 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 Port towards downstream LSR has been altered
The optional Routable IP address in the Impairment Section is for
transit LSR to send the Path Condition Impairment Notification back
to the source LSR. Since BFD control frames between a pair of LSRs
are exchanged frequently, it is not necessary for the transit node to
send the Path Condition Impairment Notification every time there is
BFD traversed. In order to minimize work required on transit node,
source node takes the responsibility to indicate if it needs a
notification from transit node when the transit node experiences
downstream link impairment. When the Routable IP address is included
in the Impairment Section of BFD control frame, transit node SHALL
send back a Path Condition Impairment Notification to the Source LSR
when impairment is encountered.
The source LSR CAN perform the following actions upon receiving the
Path Condition Impairment Notification from transit LSR.
send more sophisticated inquiry messages to the transit LSR to
diagnose what happened
trigger performance monitoring scheme 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
Dunbar, So Expires July 19, 2010 [Page 5]
Internet-Draft Path Condition Marking using BFD January 2010
activate the secondary/protection path
reduce admission rate (in the case of LTE eNodeB).
When a transit node receives a BFD and its downstream link is
impaired or altered, it CAN perform the following actions:
1. If the BFD doesn't have the Impairment section, do nothing.
Simply forward the BFD to the next hop.
Otherwise:
2. The transit node SHALL set the ImpairmentValue field accordingly
and then forward the BFD to the next hop.
3. If Routable IP address is included in the Impairment section,
the transit LSR SHALL construct the Path Condition Impairment
Notification message and send it to the Source LSR.
4. Path Condition Impairment Notification
Though a new message format can be specified for transit node to send
the Path Condition Impairment Notification, it is always easier for
LSR to use an existing message type, like LSP-Ping Echo Reply
[RFC4379], with some minor modification to do the job.
This draft suggests a message type similar to the MPLS-Ping Echo
reply which is specified in Section 3 of RFC 4379 to indicate the
Path Condition Impairment Notification with the following changes:
RFC 4379 specifies that the Message Type of the LSP-Ping has one of
the two values. This draft suggests adding a new value to indicate
that the message is for Path Condition Impairment Notification in
responding to BFD:
Value Meaning
-------- --------
1 MPLS echo request [RFC 4379]
2 MPLS echo reply [RFC 4379]
3 Path Condition Impairment Notification in responding to
BFD
Dunbar, So Expires July 19, 2010 [Page 6]
Internet-Draft Path Condition Marking using BFD January 2010
[MPLS-Ping-Enhanced] introduced Downstream Detailed Mapping TLV. This 1 draft suggests adding a new "Downstream Path Condition" sub-TLV to
reflect the condition of the downstream link. When used alone, path
condition impairment notification SHALL be activated upon receiving a
BFD control Frame with the optional Routable IP Address included in
the Impairment Section. In this case, the Downstream Path Condition
sub-TLV SHALL be the only sub-TLV in the Downstream Detailed Map
[MPLS-Ping-Enhanced]. When the downstream path condition is included
as a sub-type, the Return Code of the echo response message SHALL be
set to "See DDM TLV for Return Code and Return SubCode".
Downstream Path Condition Impairment sub-TLV SHOULD have the
following field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PathCondSubType| Length |ImpairmentValue|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD control Header field |
(All the head fields until My Discriminator, Your Discriminator)
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ImpairmentValue is same as the value used in the BFD control
(section 3 above).
5. Receiving Path Condition Impairment Notification
It is out of the scope of this draft on what Source LSR will do upon
receiving the Path Condition Impairment Notification.
6. Manageability Considerations
This document does not add additional manageability considerations.
1 The Downstream Path Condition sub-TLV can also be included in the normal LSP-Ping
response to indicate that the downstream link, even though its connectivity is up,
is impaired. This will be a separate draft amending the MPLS-Ping-Enhanced scheme.
Dunbar, So Expires July 19, 2010 [Page 7]
Internet-Draft Path Condition Marking using BFD January 2010
7. Security Considerations
This document has no requirement for a change to the security models
within BFD.
8. IANA Considerations
A future revision of this document will present requests to IANA for
codepoint allocation.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
10. References
10.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.
[BFD] Katz, D. and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-09.txt
[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.
10.2. Informative References
[IEEE802.1au] IEEE802.1au Virtual Bridged Local Area Networks-
Amendment: Congestion Notification
Dunbar, So Expires July 19, 2010 [Page 8]
Internet-Draft Path Condition Marking using BFD January 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
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.
Dunbar, So Expires July 19, 2010 [Page 9]
Internet-Draft Path Condition Marking using BFD January 2010
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 July 19, 2010 [Page 10]