Network Working Group A. Farrel
Internet-Draft Huawei Technologies
Intended status: Informational H. Endo
Expires: January 12, 2012 Hitachi, Ltd.
R. Winter
NEC
Y. Koike
NTT
M. Paul
Deutsch Telekom
July 11, 2011
Handling MPLS-TP OAM Packets Targeted at Internal MIPs
draft-farrel-mpls-tp-mip-mep-map-04
Abstract
The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) describes how Maintenance
Entity Group Intermediate Points (MIPs) may be situated within
network nodes at the incoming and outgoing interfaces.
This document describes a way of forming OAM messages so that they
can be targeted at MIPs on incoming or MIPs on outgoing interfaces,
forwarded correctly through the "switch fabric", and handled
efficiently in node implementations where there is no distinction
between the incoming and outgoing MIP.
The material in this document is provided for discussion within the
MPLS-TP community in the expectation that this idea or some similar
mechanism will be subsumed into a more general MPLS-TP OAM document.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
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/.
Farrel, et al. Expires January 12, 2012 [Page 1]
Internet-Draft Internal MIP Handling July 2011
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 January 12, 2012.
Copyright Notice
Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Farrel, et al. Expires January 12, 2012 [Page 2]
Internet-Draft Internal MIP Handling July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Summary of the Problem Statement . . . . . . . . . . . . . . . 7
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 12
6. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 14
6.1. ID-based Solution . . . . . . . . . . . . . . . . . . . . 14
6.2. Using an ACH reserved bit . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Previously considered solutions . . . . . . . . . . . 21
A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. A separate channel type for the out-MIP . . . . . . . . . 21
A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Farrel, et al. Expires January 12, 2012 [Page 3]
Internet-Draft Internal MIP Handling July 2011
1. Introduction
The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM
Framework, [I-D.ietf-mpls-tp-oam-framework]) distinguishes two
configurations for Maintenance Entity Group Intermediate Points
(MIPs) on a node. It defines per-node MIPs and per-interface MIPs,
where a per-node MIP is a single MIP per node in an unspecified
location within the node and per-interface MIPs are two (or more)
MIPs per node on both sides of the forwarding engine.
In-band OAM messages are sent using the Generic Associated Channel
(G-ACh) [RFC5586]. OAM messages for the transit points of
pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using
the expiration of the MPLS shim header time-to-live (TTL) field. OAM
messages for the end points of PWs and LSPs are simply delivered as
normal.
OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the Label Stack Entry (LSE) under
the top LSE [RFC5586]. In PWs, the mechanism used is the presence of
the PW Associated Channel Header (PWACH) [RFC4385].
In case multiple MIPs are present on a single node, these mechanisms
alone provide no way to address one particular MIP out of the set of
MIPs.
This document describes a way of forming OAM messages so that they
can be targeted at incoming MIPs and outgoing MIPs, forwarded
correctly through the "switch fabric", and handled efficiently in
node implementations where there is no distinction between the
incoming and outgoing MIP.
The material in this document is provided for discussion within the
MPLS-TP community in the expectation that this idea or some similar
mechanisms will be subsumed into a more general MPLS-TP OAM document.
This document is a product of a joint Internet Engineering Task Force
(IETF)/International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architecture to support the
capabilities and functionalities of a packet transport network.
Note that the acronym "OAM" is used in conformance with [RFC6291].
Farrel, et al. Expires January 12, 2012 [Page 4]
Internet-Draft Internal MIP Handling July 2011
2. Requirements notation
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 [RFC2119].
Farrel, et al. Expires January 12, 2012 [Page 5]
Internet-Draft Internal MIP Handling July 2011
3. Terminology
In this document we use the term in-MIP (incoming MIP) to refer to
the MIP which processes OAM messages before they pass through the
forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM
messages after they have passed the forwarding engine of the node.
The two together are referred to as internal MIPs.
Farrel, et al. Expires January 12, 2012 [Page 6]
Internet-Draft Internal MIP Handling July 2011
4. Summary of the Problem Statement
Figure 1 shows an abstract functional representation of an MPLS-TP
node. It is decomposed as an incoming interface, a cross-connect
(XC), and an outgoing interface. As per the discussion in
[I-D.ietf-mpls-tp-oam-framework], MIPs may be placed in each of the
functional interface components.
------------------------
|----- -----|
| MIP | | MIP |
| | ---- | |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
Figure 1: Abstract Functional Representation of an MPLS-TP Node
Several distinct OAM functions are required within this architectural
model such as:
o CV between a MEP and a MIP
o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
MIPs
o OAM control at a MIP
o data-plane loopback at a MIP
o diagnostic tests
The MIPs in these OAM functions may equally be the MIPs at the
incoming or outgoing interfaces.
Per-interface MIPs have the advantage that they enable a more
accurate localization and identification of faults and targeted
performance monitoring or diagnostic test. In particular, the
identification of whether a problem is located between nodes or on a
particular node and where on that node is greatly enhanced. For
obvious reasons, it is important to narrow the cause of a fault down
quickly to initiate a timely, and well-directed maintenance action to
resume normal network operation.
The following two figures illustrate the fundamental difference of
using per-node and per-interface MEPs and MIPs for OAM. Figure 2
depicts OAM using per-interface MIPs and MEPs. For reasons of
Farrel, et al. Expires January 12, 2012 [Page 7]
Internet-Draft Internal MIP Handling July 2011
exposition we assume that these are located on the incoming
interfaces. Figure 3 on the other hand shows the same basic network
but for OAM operations per-interface maintenance points are
configured.
Customer| Operator's administrative | Customer
Domain | Domain | Domain
------> |<--------------------------------------->| <------
CE1 | PE1 P1 PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD LSP | o-------------------------- > |
| V-------------*-------------V |
| MEP1 MIP1 MEP2 |
BWD LSP | <---------------------------o |
| V-------------*-------------V |
| MEP1' MIP1' MEP2'|
(S1)<============>
(S2)<==========================>
Figure 2: Example of OAM relying on per-node MIPs and MEPs
To illustrate the difference between these two modes of operation, we
use fault detection as an example. Consider the case where the
client traffic between CE1 and CE2 experiences a fault. Also assume
that an on-demand CV test between PE1 and PE2 was successful. The
scenario in Figure 2 therefore leaves the forwarding engine(FW) of
PE2, the out-going interface of PE2, the transmission line between
PE2 and CE2 or CE2 itself as a potential location of the fault as on-
demand CV can only be performed on segment S2.
The per-interface model in Figure 3 allows more fine-grained OAM
operations to be performed. At first, CV on segment S'4 and in
addition CV on segment S'5 can help to rule out e.g. the forwarding
engine of PE2. This is of course only a single example, and other
OAM functions and scenarios are trivially conceivable. The basic
message is that with the per-interface OAM model, an operator can
configure smaller segments on a transport path to which OAM
operations apply. This enables a more fine-grained scoping of OAM
operations such as fault localization and performance monitoring
Farrel, et al. Expires January 12, 2012 [Page 8]
Internet-Draft Internal MIP Handling July 2011
which gives operators better information to deal with adverse
networking conditions.
Customer Operator's administrative Customer
Domain Domain Domain
------->|<--------------------------------------->|<------
CE1 | PE1 P1 PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD LSP | o-----------------------------------> |
| V-------*------*------*-----*-------V |
| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|
| |
BWD LSP | <-----------------------------------o |
| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|
(S'1)<======>
(S'2)<=============>
(S'3)<====================>
(S'4)<==========================>
(S'5)<==================================>
Figure 3: Example of OAM relying on per-interface MIPs and MEPs
Farrel, et al. Expires January 12, 2012 [Page 9]
Internet-Draft Internal MIP Handling July 2011
5. Overview
In-band OAM messages are sent using the G-ACh [RFC5586] for MPLS-TP
LSPs and MPLS-TP PWs, respectively. OAM messages for the transit
points of PWs or LSPs are delivered using the expiration of the time-
to-live (TTL) field in the top LSE of the MPLS packet header. OAM
messages for the end points of PWs and LSPs are simply delivered as
normal.
OAM messages delivered to end points or transit points are
distinguished from other (data) packets so that they can be processed
as OAM. In LSPs, the mechanism used is the presence of the Generic
Associated Channel Label (GAL) in the LSE under the top LSE
[RFC5586]. In PWs, the mechanism used is the presence of the PW
Associated Channel Header [RFC4385].
Any solution for sending OAM to the in and out-MIPs must fit within
these existing models of handling OAM.
Additionally, many MPLS-TP nodes contain an optimization such that
all queuing and the forwarding function is performed at the incoming
interface. The abstract functional representation of such a node is
shown in Figure 4. As shown in the figure, the outgoing interfaces
are minimal and for this reason it may not be possible to include MIP
functions on those interfaces. This is in particular the case for
existing deployed implementations.
Any solution that attempts to send OAM to the outgoing interface of
an MPLS-TP node must not cause any problems when such implementations
are present.
------------------
|------------ |
| MIP | |
| ---- | |
----->-| In | XC | |-->--|->---
| i/f ---- | |
|------------ |
------------------
Figure 4: Abstract Functional Representation of an Optimized MPLS-TP
Node
Lastly, OAM must operate on MPLS-TP nodes that are branch points on
point-to-multipoint (P2MP) trees. That means that it must be
possible to target individual outgoing MIPs as well as all outgoing
MIPs in the abstract functional representation shown in Figure 5, as
Farrel, et al. Expires January 12, 2012 [Page 10]
Internet-Draft Internal MIP Handling July 2011
well as to handle the optimized P2MP node as shown in Figure 6.
--------------------------
| -----|
| | MIP |
| ->-| |->----
| | | Out |
| | | i/f |
| | -----|
|----- | -----|
| MIP | ---- | | MIP |
| | | |- | |
----->-| In |->-| XC |--->-| Out |->----
| i/f | | |- | i/f |
|----- ---- | -----|
| | -----|
| | | MIP |
| | | |
| ->-| Out |->----
| | i/f |
| -----|
--------------------------
Figure 5: Abstract Functional Representation of an MPLS-TP Node
Supporting P2MP
------------------
| ->-|->----
| | |
|------------ | |
| | | |
| MIP ---- | | |
| | | |- |
----->-| In | XC | |--->-|->----
| i/f | | |- |
| ---- | | |
| | | |
|------------ | |
| | |
| ->-|->----
------------------
Figure 6: Abstract Functional Representation of an Optimized MPLS-TP
Node Supporting P2MP
In summary, the solution for OAM message delivery must support the
Farrel, et al. Expires January 12, 2012 [Page 11]
Internet-Draft Internal MIP Handling July 2011
following features:
o Forwarding of OAM packets exactly as data packets.
o Delivery of OAM messages to the correct MPLS-TP node.
o Direction of OAM instructions to the correct MIP within an MPLS-TP
node.
o Packet inspection at the incoming and outgoing interfaces must be
minimized.
Note that although this issue appears superficially to be an
implementation matter local to an individual node, the format of the
message needs to be standardised so that:
o An upstream MEP can correctly target the outgoing MIP of a
specific MPLS-TP node.
o A downstream node can correctly filter out any OAM messages that
were intended for its upstream neighbor's outgoing MIP, but which
were not handled there because the upstream neighbor is an
optimized implementation.
Note that the last bullet point describes a safety net and an
implementation should avoid that this situation ever arises.
5.1. Rejected Partial Solution
A reject solution is depicted in Figure 7. All data and non-local
OAM is handled as normal. Local OAM is intercepted at the incoming
interface and delivered to the MIP at the incoming interface. If the
OAM is intended for the incoming MIP it is handled there with no
issue. If the OAM is intended for the outgoing MIP it is forwarded
to that MIP using some internal messaging system that is
implementation-specific.
------------------------
|----- -----|
local OAM ----->-| MIP |----->------| MIP |
| | ---- | |
data =====>=| In |=>=| XC |=>=| Out |=>==== data
non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
|----- ---- -----|
------------------------
Figure 7: OAM Control Message Delivery Bypassing the Switching Fabric
Farrel, et al. Expires January 12, 2012 [Page 12]
Internet-Draft Internal MIP Handling July 2011
This solution is fully functional for the incoming MIP. It also
supports control of data loopback for the outgoing MIP, and can
adequately perform some OAM features such as interface identity
reporting at the outgoing MIP.
However, because the OAM message is not forwarded through the switch
fabric, this solution cannot correctly perform OAM loopback,
connectivity verification, LSP tracing, or performance measurement.
Farrel, et al. Expires January 12, 2012 [Page 13]
Internet-Draft Internal MIP Handling July 2011
6. Possible Solutions
We briefly present here a number of possible solutions to the problem
outlined so far with the hope that the WG will quickly converge
towards adopting one of them. The appendix of this document already
contains a few solutions that the authors have discarded which have
been left in the document for informational purposes.
6.1. ID-based Solution
An ID-based solution leverages existing identification information in
OAM messages. OAM solutions therefore need to individually make sure
that enough of that information is present to support the per-
interface model. In particular, the MIP identifiers as described in
[I-D.ietf-mpls-tp-identifiers] need to be present in OAM messages.
[I-D.ietf-mpls-tp-identifiers] defines a format that supports the
per-interface model which is sufficient for this purpose. In
addition, some constraints must be agreed on.
From a requirements-perspective this means:
o Forwarding of OAM packets exactly as data packets - This way of
internal-MIP addressing has no implications on the way data
packets and non-local OAM packets are handled. The TTL processing
remains untouched. This also means that the TTL will expire on
the ingress.
o Delivery of OAM messages to the correct MPLS-TP node - The TTL
addresses the node.
o Direction of OAM instructions to the correct MIP within an MPLS-TP
node - The ID information containted in the OAM packet is used to
tell whether the packet is for the in or out-MIP.
o Packet inspection at the incoming and outgoing interfaces must be
minimized - packet inspection becomes a bit more complicated since
the required information can be in different places for different
types of OAM.
o An upstream MEP can correctly target the outgoing MIP of a
specific MPLS-TP node - this is simple as the TTL addresses the
node and the ID information in the packet addresses the respective
MIP.
o A downstream node can correctly filter out any OAM messages that
were intended for its upstream neighbor's outgoing MIP, but which
were not handled there because the upstream neighbor is an
optimized (legacy) implementation - OAM messages expire on the
Farrel, et al. Expires January 12, 2012 [Page 14]
Internet-Draft Internal MIP Handling July 2011
ingress so the legacy upstream neighbor will process the packet.
Since the ID information is not correct, the node will discard the
packet. Leakage should therefore not occur.
6.2. Using an ACH reserved bit
The ACH contains eight reserved bits which currently all need to be
set to zero and ignored on reception. One bit could be reserved as
an out-MIP address flag. In other words, in case the bit is set, the
out-MIP is addressed. An advantage of this approach is that there is
no semantic overlap with anything that exists today, as the bits are
not in use. Existing implementations need to ignore it. That means
that existing implementations will process the OAM packets at the in-
MIP/per-node MIP.
From a requirements-perspective this means:
o Forwarding of OAM packets exactly as data packets - This way of
internal-MIP addressing has no implications on the way data
packets and non-local OAM packets are handled. The TTL processing
remains untouched.
o Delivery of OAM messages to the correct MPLS-TP node - The TTL
addresses the node.
o Direction of OAM instructions to the correct MIP within an MPLS-TP
node - The newly defined bit addresses the correct place within
the node (0 = in-MIP and 1 = out-MIP).
o Packet inspection at the incoming and outgoing interfaces must be
minimized - packet inspection requires to check an additional bit,
which however is at a fixed location.
o An upstream MEP can correctly target the outgoing MIP of a
specific MPLS-TP node - this is simple as the TTL addresses the
node and the new flag indicates the place within the node.
o A downstream node can correctly filter out any OAM messages that
were intended for its upstream neighbor's outgoing MIP, but which
were not handled there because the upstream neighbor is an
optimized (legacy) implementation - Since the TTL will expire on
the node the message will be processed by it. Since it is not
targeted at that MIP, it will discard it.
Farrel, et al. Expires January 12, 2012 [Page 15]
Internet-Draft Internal MIP Handling July 2011
------------------------
|----- -----|
| MIP | ---- | MIP |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
-----------------
in-MIP | Label=x | TTL=0 |---
OAM |-----------------| |
| GAL | TTL=m | |
|-----------------| |
| ACH res bit x=0 | |
----------------- |
<------
----------------- -----------------
out-MIP | Label=x | TTL=0 |--------------->| Label=y | TTL=0 |---
OAM |-----------------| |-----------------| |
| GAL | TTL=m | | GAL | TTL=m | |
|-----------------| |-----------------| |
| ACH res bit x=1 | | ACH res bit x=1 | |
----------------- ----------------- |
<-------
Figure 8: Packet Formats for in and out-MIP OAM (for LSPs)
Farrel, et al. Expires January 12, 2012 [Page 16]
Internet-Draft Internal MIP Handling July 2011
7. Security Considerations
OAM security is discussed in [I-D.ietf-mpls-tp-oam-framework] and
[I-D.manral-mpls-tp-oam-security-tlv].
OAM can provide useful information for detecting and tracing security
attacks.
OAM can also be used to illicitly gather information or for denial of
service attacks and other types of attack. Implementations therefore
are required to offer security mechanisms for OAM. Deployments are
strongly advised to use such mechanisms.
Mixing of per-node and per-interface OAM on a single node is not
advised as OAM message leakage could be the result.
Farrel, et al. Expires January 12, 2012 [Page 17]
Internet-Draft Internal MIP Handling July 2011
8. IANA Considerations
This revision of this document does not make any requests of IANA.
Farrel, et al. Expires January 12, 2012 [Page 18]
Internet-Draft Internal MIP Handling July 2011
9. Acknowledgments
The authors gratefully acknowledge the substantial contributions of
Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros
for interesting input to this document through discussions.
Farrel, et al. Expires January 12, 2012 [Page 19]
Internet-Draft Internal MIP Handling July 2011
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
10.2. Informative References
[I-D.ietf-mpls-tp-identifiers]
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
Identifiers", draft-ietf-mpls-tp-identifiers-06 (work in
progress), June 2011.
[I-D.ietf-mpls-tp-oam-framework]
Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A.,
Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher,
N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R.
Winter, "Operations, Administration and Maintenance
Framework for MPLS-based Transport Networks",
draft-ietf-mpls-tp-oam-framework-11 (work in progress),
February 2011.
[I-D.manral-mpls-tp-oam-security-tlv]
Manral, V., "MPLS-TP General Authentication TLV for
G-ACH", draft-manral-mpls-tp-oam-security-tlv-00 (work in
progress), June 2009.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.
Farrel, et al. Expires January 12, 2012 [Page 20]
Internet-Draft Internal MIP Handling July 2011
Appendix A. Previously considered solutions
A.1. GAL TTL
The use of the GAL TTL has been considered before. This transforms
the GAL TTL into some kind of node-internal TTL, i.e. a GAL TTL of 0
would address the in-MIP and a GAL TTL of 1 the out-MIP. The main
drawback of this approach is that it (as of now at least) would only
be applicable to LSPs and not to PWs.
A.2. A separate channel type for the out-MIP
This approach would require two channel types for the exact same OAM
type, one to address the in-MIP and another one to address the out-
MIP. This seems like a waste of channel types, however it appears
that there is no expected shortage of them. Legacy nodes will
discard the packets as the new channel types are unkonwn. Having two
channel types for the same OAM however feels a bit hacky.
A.3. Decrement TTL once per MIP
Decrementing the TTL more than once per node seems a "natural" way of
per-interface MIP addressing since TTL expiry is all that is needed
for the per-node MIP case. In other words, by decrementing the TTL
once per MIP (twice per node) no extra mechanism is needed to solve
the internal MIP addressing problem. The solution has been discarded
since it does not represent the typical mode of network operation
today (since also for normal data packets the TTL needs to be
decremented more than once).
Farrel, et al. Expires January 12, 2012 [Page 21]
Internet-Draft Internal MIP Handling July 2011
Authors' Addresses
Adrian Farrel
Huawei Technologies
Email: adrian.farrel@huawei.com
Hideki Endo
Hitachi, Ltd.
Email: hideki.endo.es@hitachi.com
Rolf Winter
NEC
Email: rolf.winter@neclab.eu
Yoshinori Koike
NTT
Email: koike.yoshinori@lab.ntt.co.jp
Manuel Paul
Deutsch Telekom
Email: Manuel.Paul@telekom.de
Farrel, et al. Expires January 12, 2012 [Page 22]