Internet DRAFT - draft-allan-mpls-a-bit
draft-allan-mpls-a-bit
Internet Draft David Allan
Document: draft-allan-mpls-a-bit-00.txt Nortel Networks
Category: Standards Track April 2003
The Case for the 'A' Bit in the MPLS and IP PID
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright(C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo describes the underlying rationale for inclusion of the
LSR alert bit in the proposed MPLS payload ID.
Sub-IP ID Summary
[to be removed when published]
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
Fits in the MPLS, and PWE3.
WHY IS IT TARGETED AT THESE WGs
This draft addresses a number of issues associated with
instrumenting/controlling MPLS LSPs and PWs in general.
Allan et.al Expires October 2003 Page 1
The Case for the 'A' Bit
1. Introduction
The internet draft [MPLSPID] had numerous commonalities with other
proposals for an MPLS PID. All proposals include some well known
value in the first nibble, and a means of identifying the protocol
used in the subsequent payload. The only significant difference in
the proposals is that [MPLSPID] includes an 'LSR alert' bit. This
memo describes the underlying rationale for inclusion of the 'LSR
alert' or 'A' bit.
2. The 'A' bit mechanism
The 'A' bit is provided as an alternative mechanism to the router
alert reserved label [RFC3032]. Intermediate LSRs along an LSP that
recognize the MPLS and IP PW payload ID must process the protocol
PDU when the 'A' bit is set in the control word. The intent is to
provide a hop-by-hop mechanism that is unaffected by deployed ECMP
(which may impact fate sharing between RA labeled flows and the
original LSP) and maximizes commonality of forwarding between hop-
by-hop and normal LSP flows in the internal implementation of
labeled payload handling.
Specification of the 'A' bit would require that compliant LSRs check
the MPLS top of stack label entry and if the 'S' bit is set, examine
the first nybble of each packet. If it is the extended Payload CW,
check the alert bit and if so, process the payload (which in most
cases will also include subsequently forwarding the payload).
3. Discussion
There are aspects of the direction that proactive fault detection
has taken that will introduce as many problems as are solved. This
is an artifact of the currently available mechanisms for
distinguishing fault detection messaging (discussed extensively in
[FRAMEWORK]).
One specifically pathological mode of failure is misdirection of
traffic as this is a defect NOT detected or recovered by means other
than path specific testing. Misdirection of traffic is a prime
motivation of MPLS OAM efforts [REQUIRE]. Unlike problems detected
adjacent to the source of the fault such as link or node failures,
detection of misdirection via e2e probing will have no associated
IGP notification that could act as a coordinating mechanism for how
nodes remote to the problem respond.
MP2P LSPs and label stacking mean that large numbers of LSP
ingresses may be impacted by a problem with a single forwarding
table entry. One option for detection of such problems is the use of
LSP-PING [LSP-PING] proactively on some number of the potentially
impacted LSPs. A defect in that table entry will misdirect all of
the associated ping transactions. This will be reported to the ping
originators which in some implementations this may result in the
ping originators initiating traceroute, isolating the problem and
Allan Expires October 2003 Page 2
The Case for the 'A' Bit
alarming. The ping originators operate in an independent and
unsynchronized manner so a defect may trigger a significant amount
of redundant diagnostic traffic and alarms.
Use of a one way transaction (either LSP-PING in 'do not reply' mode
or the simpler FEC-CV [FEC-CV]) is a significant improvement as
responsibility for handling the problem is pushed to a much reduced
set of network elements. However this is still limited in recovery
capability as the egress would only know it is some arbitrary number
of hops downstream of the problem and would still need to take
further action to isolate and recover from the problem. This would
have security implications if it simply generated unsolicited fault
notifications to untrusted peers some arbitrary number of hops
across the network.
When there are nested LSPs stacked on a misdirected LSP, the set of
nested labels will also be misdirected. Some will not progress past
the next LSR when there is no corresponding ILM but some number will
collide with existing label values, and merge their traffic into
existing LSPs. When combined with e2e testing even with an egress
detection paradigm, this will result in a large number of LSRs in
the network independently detecting a common failure.
With that as the background, one conclusion we have come to is that
misbranching detection is BEST performed hop by hop such that
detection will frequently occur within one hop of the fault and
prior to any significant fan out of misdirected nested LSPs. This
minimizes the number of alarms associated with the fault, and may
permit some misbranching faults to be automatically corrected.
4. Current hop by hop Mechanisms
4.1 Router Alert
The current hop-by-hop mechanism is to prepend the current label
stack with the Router Alert label. Use of the router alert label on
top of the label under test will be subject to significant
implementation variations that will impact the validity of any hop-
by-hop testing using the router alert mechanism.
The combination of ECMP (or other hashing based load spreading
mechanisms) and label stacking means that use of any reserved label
will interfere with fate sharing of flows. A path may fail or be
misdirected and not be detected by probes pre-pended with the router
alert label.
We believe that the above two reasons disqualify use of the router
alert label from consideration as a solution.
4.2 TTL Manipulation
Alternately use of TTL=1 to relay messages hop by hop down the LSP
will promptly break if the mechanism is not ubiquitously deployed.
Allan Expires October 2003 Page 3
The Case for the 'A' Bit
Non-implementation breaks the chain instead of simply forwarding the
message transparently. This disqualifies hop by hop TTL manipulation
as a candidate solution.
Ideally some method of identifying hop-by-hop flows with minimal
impact to label stack semantics is required (hence the 'A' bit).
5. Load Spreading
Load spreading can occur in the MPLS architecture when an FEC to
NHLFE mapping or ILM mapping resolves to multiple NHLFEs. The
ability to distinguish hop by hop probing of the network suggests a
way forward. Hop-by-hop forwarding of misbranching probes can
exercise the set of NHLFEs via any of several mechanisms:
a) Replication: an incoming probe is simply replicated across the
set of NHLFEs.
b) Round-robin: an NHLFE selector selects the next NHLFE in the set
for forwarding upon receipt of a misbranching probe.
c) Probe examination such that a probe from any given source or
directed to a src/dest pair always resolves to a specific NHLFE.
It should be noted that proactive detection of a problem will have
different requirements that fault isolation. A round robin approach
will not provide consistent forwarding from probe to probe as there
is no guarantee that two identical probes will share common
forwarding, nor is it required to in this application. LSP-PING when
used to isolate a fault and inserted either e2e or employing TTL
exhaust would be required to produce consistent results for a given
LSP and src/dest tuple and would do so independent of the hop-by-hop
technique.
A round robin approach would most likely produce acceptable
detection times without magnifying the probe load on the network. It
would be expected to provide faster detection times than random
payload manipulation techniques (altering a 127./8 destination
address), and compared to when traceroute was used to establish a
specific 127./8 test plan, would respond to topology changes faster
than periodic traceroute.
6. Protocol Options
There are currently two protocol proposals that have suitable
functional characteristics for hop-by-hop fault detection. They do
have differences in implementation complexity. In both cases they
would be used with the MPLS and IP PW payload ID.
6.1 LSP-PING
One would be the use of LSP-PING in either 'do not reply' mode or to
modify the reply semantics such that a reply was only generated when
either a fault was detected or the LSP egress was reached. The LSR
Allan Expires October 2003 Page 4
The Case for the 'A' Bit
detecting the fault is delegated responsibility for reporting the
problem and initiating corrective action.
Each LSR intercepting the 'alert' designated ping message would
check the FEC TLV and compare this with the FEC for the LSP. If the
FEC was invalid, the If the FEC TLV contained a valid FEC, the probe
would then be forwarded to the next LSR. This would be an
improvement over simply running traceroute continuously as the
number of messages would be significantly reduced.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |A| rsvd. | PA | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// UDP Header //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV type = Target FEC Stack | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubTLV type = IPv4 FEC | Length =5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask |
+---------------+
Figure 1: LSP-PING (IPv4 FEC) with MSLS & IP Payload CW
Allan Expires October 2003 Page 5
The Case for the 'A' Bit
Note that if adopted, the option of specifying that the payload
following the IP PW control word is an IP protocol, then if 'do not
reply' mode is used, the LSP-PING PDU could be simplified by
dispensing with the IP and UDP headers.
6.2 FEC-CV
The other would be the use of FEC-CV as proposed for Y.1711. Each
LSR intercepting the 'alert' designated FEC-CV message would compare
the FEC-filter with the expected value (Boolean 'AND' operation). If
no mismatch is detected then the probe would be forwarded to the
next LSR. FEC-CV is a one way probe message so it would simply be
discarded at the LSP egress.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |1| rsvd. | PA | Protocol ID (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function (=7) | Reserved (=0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| TTSI |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| FEC Filter |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (=0) | BIP 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC-CV PDU w. Payload ID CW
7. Interlayer coordination
When a misbranching defect occurs for an LSP that transports LSPs
(e.g. TE trunk or PWs on a PSN), it is desirable to minimize the
number of points detecting the problem.
There are two scenarios that can be considered:
1) The fault misdirects MPLS LSPs without changing the MPLS level
(label swap problem).
When an LSP is detected as being in a misforwarded state, probably
the most secure response that the network can offer is to silently
discard all traffic or at least all labeled traffic transported by
the LSP. This has the additional benefit of not forwarding any
misbranching probes that have been inserted into client LSPs. This
Allan Expires October 2003 Page 6
The Case for the 'A' Bit
will have the desirable properly of ensuring client LSPs will not
alarm.
2) The fault misdirects traffic by altering the MPLS level (push or
pop problem).
A premature pop fault fault will result in a significant number of
misbranching defects being detected by the immediately adjacent
LSRs. It may also result in no-ILM conditions in the LSR where the
unexpected pop occurred. LSRs should limit the rate of management
notifications associated with misdirection of traffic.
An unexpected push in the network would be more difficult to isolate
if the traffic merged with an existing LSP. Detection of the fault
would not occur until the egress of the LSP merged into was reached
by any probes.
8. Implications of partial deployment
Partial deployment diminishes but does not eliminate the value of
the hop-by-hop audit. Nodes that do not implement 'A' bit
functionality will simply forward the misbranching probes without
processing them.
If the fault has occurred in an MP2P LSP, and for security reasons
or other operational reasons detection of such a fault leads to
silent discard of all traffic, then detection by virtually any node
upstream of the egress node will reduce the amount of traffic
impacted by the misbranching fault.
9. Conclusions
Most simply expressed, IP is hop by hop forwarding. Hop by hop
detection of MPLS forwarding problems for LSPs set up with via LDP
is consistent with the IP paradigm whereas proactive e2e path
testing for the same is not.
Proactive hop by hop verification of forwarding is only practical if
a sufficiently lightweight mechanism existed such that the network
was not degraded by proactive probing. Section 6 explores some
possibilities and suggests that this is not an insurmountable
obstacle.
Hop by hop verification of forwarding requires a mechanism for
distinguishing hop-by-hop probes that has maximum commonality with
the handling of the label of interest and immunity to deployed ECMP.
This is what motivates the 'A' bit proposal.
10.References
[MPLSPID] Allan, D., 'The MPLS and IP PW Payload ID', Internet
Draft, draft-allan-mpls-pid-00, April 2003
Allan Expires October 2003 Page 7
The Case for the 'A' Bit
[FEC-CV] Allan, D., 'Overview of the FEC-CV proposed extension
to the Y.1711 protocol', IETF Internet Draft, draft-
allan-fec-cv-overview-00.txt
IETF Internet Draft, draft-allan-mpls-oam-frmwk-04,
February 2003
[LSPPING] Pan, P. et.al.,'Detecting Data Plane Liveness',
Internet Draft, draft-ietf-mpls-lsp-ping-02, April 2003
[REQUIRE] Nadeau et.al., 'OAM Requirements for MPLS Networks',
IETF Internet Draft, draft-nadeau-ietf-oam-
requirements-01, February 2003
11.Author's Address
David Allan
Nortel Networks Phone: 1-613-763-6362
3500 Carling Ave. Email: dallan@nortelnetworks.com
Ottawa, Ontario, CANADA
12.Full Copyright Statement
"Copyright (C) The Internet Society (2003). Except as set forth
below, authors retain all their rights.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
rights in submissions defined in the IETF Standards Process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
