Internet DRAFT - draft-snyder-bfd-proxy-connections-monitored-links
draft-snyder-bfd-proxy-connections-monitored-links
Internet Engineering Task Force B. Snyder
Internet-Draft iDirect Technologies
Intended status: Informational N. Akiya
Expires: November 6, 2014 Cisco Systems
May 5, 2014
BFD Proxy for Connections over Monitored Links
draft-snyder-bfd-proxy-connections-monitored-links-00
Abstract
This document describes a Bidirectional Forwarding Detection (BFD)
proxy mechanism to allow intermediate networking equipment (ex:
Satellite HUB/Modem) to intercept BFD packets and to generate BFD
packets to relay the health of connection monitored links.
Note that this is an informational document that does not propose any
changes to the BFD protocol.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 6, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Snyder & Akiya Expires November 6, 2014 [Page 1]
Internet-Draft BFD proxy May 2014
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. BFD Proxy Placement . . . . . . . . . . . . . . . . . . . . . 5
4. BFD Proxy Procedures . . . . . . . . . . . . . . . . . . . . 5
4.1. BFD Control Packet Interception . . . . . . . . . . . . . 5
4.2. OAM Object . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. BFD Proxying . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Outroute Considerations . . . . . . . . . . . . . . . . . 8
4.5. Inroute Considerations . . . . . . . . . . . . . . . . . 8
5. Possible Integration Improvements . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
1.1. Terminology
The following acronyms/terminologies are used in this document:
o BFD - Bidirectional Forwarding Detection
o DLEP - Dynamic Link Exchange Protocol
o L2 - Layer 2
o L3 - Layer 3
o Outroute - The broadcast link from hub to modem(s) in a satellite
network.
Snyder & Akiya Expires November 6, 2014 [Page 2]
Internet-Draft BFD proxy May 2014
o Downstream - Synonymous to Outroute.
o OTA - Over the Air
o Inroute - The unicast uplink that a modem transmits to the hub
side on in a satellite network.
o Upstream - Synonymous to Inroute.
1.2. Background
Bidirectional Forwarding Detection (BFD) is an application agnostic
and link type independent keep alive protocol which has widely been
implemented and deployed. The BFD protocol can be configured with a
fast interval to provide rapid failure detection or configured with a
slower interval to provide slower failure detection. The faster the
interval, the more BFD packets are transmitted and received,
consuming more system and network resources.
Some links have connection monitoring functionality of its own, and
some of these connection monitored links have constraints (ex:
limited or expensive bandwidth). Applications over such links often
still desire rapid failure detection through exchanging keep-alive
packets (ex: BFD). However, the consequence of such can
significantly degenerate the value of the links. For example,
running BFD over a link with limited bandwidth can result in a
significant portion of the bandwidth being consumed by BFD packets.
One example of such scenario is:
+------ MDM1 --- RTR1
|
UpstreamRTR --- HUB --- <SAT> --- MDM2 --- RTR2
|
+------ MDMn --- RTRn
Figure 1: Star Satellite Network
The HUB components consist of a protocol stack which processes and
inspects all outbound packets in order to optimize traffic for a high
delay low bandwidth environments. (Ex: TCP proxy, compression,
encryption). This stack also contains a L2 switch to demultiplex
outroute traffic towards the proper modem via a MAC learning switch.
In this component is also station keeping algorithms and QOS
schedulers.
The MDM components have the same protocol stack (without the
demultiplexing required) to optimize the traffic flow for the TDMA
Snyder & Akiya Expires November 6, 2014 [Page 3]
Internet-Draft BFD proxy May 2014
inroutes. The interfaces of a modem are 1 RF interface and 1 to 8
ethernet interfaces.
When routers connected to HUB and MDMs run BFD to monitor the L3
reachability through the Satellite network, expensive Satellite
bandwidth gets consumed with large number of BFD packets traversing
over it.
Dynamic Link Exchange Protocol (DLEP), [I-D.ietf-manet-dlep], tackles
this problem by introducing a protocol that can communicate the state
of monitored links to routing devices. DLEP also maintains and
communicates an extensive set of information (ex: link quality). A
wide range of DLEP responsibilities result in a large effort for
vendors to develop this protocol. DLEP, in addition, will require
further effort to get integrated into various applications (ex: IGP)
for the information to be beneficial.
BFD, on the other hand, has widely been implemented and deployed. If
applications, already capable of speaking BFD, only require keeping
track of a connection state over monitored links, and not any other
information provided by DLEP, then the BFD proxy, described in this
document, can be implemented on intermediate networking equipment to
allow:
o Connected network equipment (i.e. routers) to continue using BFD
for continuity check.
o BFD packets to consume minimal bandwidth on monitored links.
2. Overview
This informational document describes a BFD proxy mechanism that
allows for connection monitoring intermediate networking equipment
(ex: Satellite HUB/Modem) to use BFD packets in order to communicate
the state of monitored links whilst significantly reducing the
network bandwidth consumed by BFD packets.
The BFD proxy is a link state aware module that resides on the
intermediate networking equipment, and intercepts all BFD packets
coming in from the connected network equipment.
The first task of the BFD proxy is to transmit BFD control packets to
the connected network equipment in order to communicate the state of
monitored links, based on its knowledge of link state. The BFD proxy
can inject BFD STATE change events towards the connected network
equipment. When the device under monitoring is present, the BFD
proxy can inject BFD packets with BFD_UP state. When the device
Snyder & Akiya Expires November 6, 2014 [Page 4]
Internet-Draft BFD proxy May 2014
under monitoring has left the network, the BFD proxy can inject BFD
packets with BFD_DOWN state.
The second task, to reduce network bandwidth is handled both at the
BFD level (by proxing) and at the L3 level. By proxing the BFD
control packets one can keep all the BFD overhead off the monitored
(and often expensive) bandwidth links. The use of BFD also allows
for network designers to configure L3 keep-alive/HELLO timers to be
increased thereby reducing OTA bandwidth usage of un-proxied data
flows. With BFD monitoring and alerting, L3 convergence is bound by
a combination of link state awareness and IGP Hello time (in either
direction). The monitored link's state (ex: satellite modem) can be
immediately propagated when transitioning between in and out of
network. Additionally, configurations and protocols will be
discussed that have been determined to be optimal to this use case.
This document will also suggest multiple integration improvements
that all interested parties (routing vendors and modem vendors) could
implement to further optimize convergence time and bandwidth usage.
The network configuration is that of a star design, where thousands
of CE routers each behind a satellite remote will attach to one hub
upstream router via desired L3 protocols. Whilst, many networks do
utilize mobility and roaming, they are always aware of whom they are
connecting too (either one or more possible HUBs, but only one at a
time). As the goal is simply to assist the routers in understanding
radio link state to optimize routing convergence, BFD is the optimal
way of meeting this need.
3. BFD Proxy Placement
The BFD proxy module MUST be placed on a system such that it meets
following two criteria:
1. The BFD proxy module can access the state of monitored links and
neighbors reachable through it.
2. The BFD proxy module can access all single-hop BFD control
packets coming in from the connected network equipment.
4. BFD Proxy Procedures
4.1. BFD Control Packet Interception
The BFD proxy module MUST intercept all single-hop BFD control
packets (referred to as BFD packets from hereon) coming in from the
connected network equipment. Criteria to identify single-hop BFD
control packets are:
Snyder & Akiya Expires November 6, 2014 [Page 5]
Internet-Draft BFD proxy May 2014
1. IP/UDP Packet
2. IP TTL 255 ([RFC5881] and for [RFC5082])
3. UDP destination port 3784 ([RFC5881])
4.2. OAM Object
The BFD proxy module SHOULD maintain an OAM object per neighbor
reachable through monitored links. This OAM object is to have the
state of the neighbor (i.e. available or not available), stores local
BFD discriminator value and caches the latest BFD packet intercepted.
When the BFD proxy module intercepts a BFD packet, destination MAC
address is used to locate the OAM object. If corresponding OAM
object is not found, then perform local checks to see if one should
get created. If the check passes, create the OAM object. Otherwise
do not create one.
4.3. BFD Proxying
Upon intercepting a BFD packet and locating a corresponding OAM
object, the BFD proxy module is to follow procedures described in
this sub-section.
1. If there is no OAM object, no further action is taken.
2. If the state of the neighbor in the OAM object is "not-
available", then no further action is taken.
3. If the State field of intercepted BFD control packet is:
* ADMIN_DOWN: Forward the intercepted packet OTA to alert the
real destination.
* DOWN: Create a BFD packet and copy the contents from
intercepted packet, with the following modifications:
+ Swap source and destination MAC addresses.
+ Swap source and destination IP addresses.
+ Set "my discriminator" field.
+ Clear "your discriminator" field.
Send constructed BFD packet to the connected network
equipment.
Snyder & Akiya Expires November 6, 2014 [Page 6]
Internet-Draft BFD proxy May 2014
* INIT: If "your discriminator" does not match expected value,
then no further action is taken. Otherwise, create a BFD
packet and copy the contents from the intercepted packet, with
the following modifications:
+ Swap source and destination MAC addresses.
+ Swap source and destination IP addresses.
+ Swap "my discriminator" and "your discriminator" fields.
+ Set "State" field to UP.
Send constructed BFD packet to the connected network
equipment.
* UP: If "your discriminator" does not match the expected value,
then no further action is taken. Otherwise. create a BFD
packet and copy the contents from the intercepted packet, with
following modifications:
+ Swap source and destination MAC addresses.
+ Swap source and destination IP addresses.
+ Swap "my discriminator" and "your discriminator" fields.
Send constructed BFD packet to the connected network
equipment.
In addition, following procedures MAY be applied:
o When a BFD control packet is sent to the connected network
equipment, the UDP checksum is set to 0 to avoid the
recalculation.
o When the state of the neighbor in the OAM object changes from
"available" to "not-available", then the BFD proxy module SHOULD
send unsolicited BFD control packet with state field as DOWN to
the connected network equipment. If this is not done, then
absence of a "reply" BFD control packet from the BFD proxy will
cause the sending router to timeout the connection after 3 drops
(or whatever the multiplier is set too).
o Once the BFD proxy is intercepting BFD control packets and is in
UP state, Poll sequence MAY be initiated to increase values in
Minimum TX Interval and Minimum RX Interval fields to reduce the
Snyder & Akiya Expires November 6, 2014 [Page 7]
Internet-Draft BFD proxy May 2014
number of BFD control packets on the link connecting the network
equipment and the intermediate network equipment.
o Since on a Satellite Star Network configuration the outroute and
inroute have different bandwidth considerations, there are unique
integration concerns which are described below
4.4. Outroute Considerations
In a star satellite network, the outroute is a broadcast channel
which all remotes receive. While there need not be any restrictions
on L3 routing protocols, it does naturally follow that an IGP is a
good choice. Specifically, one which allows for asynchronous timers.
Terrestrial convergence timing with BFD (sub second) is in the most
common error cases (rainfade, mobility switching) not a realistic
goal as the RF algorithms that determine out of network will take on
the order of seconds (15 in this specific case). Therefore should a
modem leave the network for any reason, the minimum convergence time
at the hub side is 15 seconds plus BFD timing to recognize the link
loss. Hence, the goal being to minimize bandwidth overhead to make
this as short as possible above layer 1 timing. A further
consideration is convergence timing when a modem comes back into
network. If the L3 timers are made too high, then it can take too
long to recognize a positive network state. The outroute being a
broadcast medium, can work well within these parameters if for
instance the outroute L3 hello timing was every 5 seconds. That's
only 1 multicast hello packet to cover the entire network and will
bound the convergence time to within 5 seconds.
4.5. Inroute Considerations
On the inroute, network bandwidth is much harder to come by, because
the aggregate throughput of all inroutes is shared amongst all modems
(potentially numbering in the tens of thousands), and is very
expensive. Also, it is unicast to the hub side only. Therefore any
decisions made here on timing and data transmissions must scale to
the tens of thousands in design principles. This fact is the
catalyst for preferring asynchronous timers. Ideally, one can rely
on the hello packet of a multicast outroute to kick off convergence,
and the hello timing of the inroute can be tuned down as much as
possible, to optimize inroute usage. This is possible with EIGRP and
IS-IS protocols. Unfortunately, BGP and OSPF require synchronized
timers, which means it is impossible to weigh equally the convergence
timing while protecting inroute bandwidth.
Additionally, further integration simplicity can optionally be
achieved if desired. Notice the timing of 15 seconds to recognize
Snyder & Akiya Expires November 6, 2014 [Page 8]
Internet-Draft BFD proxy May 2014
modem link state is also 3 (a common multiplier setting) times the 5
seconds (common hello message timing). Therefore, it is possible, if
one is only interested in monitoring link state, to not utilize BFD
on all the remote LANs, as 15 seconds is enough time for the L3
messaging to alert the router to a network issue and just about the
same time that the hub side will notice. This is useful to simplify
operational complexity and management of the thousands or tens of
thousands of installed networks. If one would like BFD to monitor
modem LAN state as well, then it would be required regardless.
5. Possible Integration Improvements
The following improvements could help with overhead and convergence
timing in all monitored network environments. They can require
changes on routing or modem equipment to further optimize these types
of networks:
o BFD timer - Allowing for connected network equipment to configure
a high BFD interval value. One of BFD's missions is to support
sub second failure notification. This document puts forth a
useful situation in which BFD is a great help, but does not
require such strict timing. In fact, it would scale better with
much looser restrictions on timer configuration.
o BFD demand mode implementation - If vendors had implemented demand
mode, it would be possible for the BFD proxy to send D bit to the
connected network to significantly minimize BFD packets traversing
over local link connected to the network equipment, without
tweaking Minimum TX Interval and Minimum RX Interval values. This
would reduce processing of BFD packets by the BFD proxy module
even further.
o BFD protocol - Adding into the core protocol the notion of a
proxier could assist with support of authentication in this use
case, if desired.
6. Security Considerations
The proxying by the BFD proxy module will require additional
considerations (i.e. knowing authentication types/keys of each
neighbor) to handle BFD packets with BFD authentication data
(described in Section 6.7 of [RFC5880]. This document only describes
procedures to handle BFD packets without BFD authentication data.
However, because the mechanism is only applicable to single-hop BFD
([RFC5881]) and GTSM (i.e. check for TTL=255) already provides
fairly strong security, lack of BFD authentication support is not
considered threatening.
Snyder & Akiya Expires November 6, 2014 [Page 9]
Internet-Draft BFD proxy May 2014
7. IANA Considerations
This document does not define any code points.
8. Acknowledgements
Authors would like to thank Adrian Farrel for providing a suggestion
to generalize the solution to all monitored links.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
2010.
9.2. Informative References
[I-D.ietf-manet-dlep]
Ratliff, S., Cisco, C., Harrison, G., Jury, S., and D.
Satterwhite, "Dynamic Link Exchange Protocol (DLEP)",
draft-ietf-manet-dlep-05 (work in progress), February
2014.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
Authors' Addresses
Brian Snyder
iDirect Technologies
Email: bsnyder@idirect.net
Nobo Akiya
Cisco Systems
Email: nobo@cisco.com
Snyder & Akiya Expires November 6, 2014 [Page 10]
