One document matched: draft-farrel-mpls-tp-mip-mep-map-03.txt
Differences from draft-farrel-mpls-tp-mip-mep-map-02.txt
Network Working Group A. Farrel
Internet-Draft Huawei Technologies
Intended status: Informational H. Endo
Expires: April 18, 2011 Hitachi, Ltd.
R. Winter
NEC
October 15, 2010
Handling MPLS-TP OAM Packets Targeted at Internal MIPs
draft-farrel-mpls-tp-mip-mep-map-03
Abstract
The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) describes how Maintenance
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/.
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
Farrel, et al. Expires April 18, 2011 [Page 1]
Internet-Draft Internal MIP Handling October 2010
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2011.
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Farrel, et al. Expires April 18, 2011 [Page 2]
Internet-Draft Internal MIP Handling October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
3. Summary of the Problem Statement . . . . . . . . . . . . . . . 6
3.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 9
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Processing of Data and Non-Local OAM . . . . . . . . . . . 13
4.2. MIP Identification . . . . . . . . . . . . . . . . . . . . 13
4.3. In-MIP Processing . . . . . . . . . . . . . . . . . . . . 14
4.4. Out-MIP Processing . . . . . . . . . . . . . . . . . . . . 14
4.5. Processing at P2MP Branch Nodes . . . . . . . . . . . . . 15
4.5.1. Out-MIP Processing . . . . . . . . . . . . . . . . . . 15
4.6. Processing When There is No Out-MIP . . . . . . . . . . . 16
5. Enhanced Proposed Solutions . . . . . . . . . . . . . . . . . 17
5.1. Incoming MIP Filtering . . . . . . . . . . . . . . . . . . 17
5.2. Outgoing MIP Label . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Farrel, et al. Expires April 18, 2011 [Page 3]
Internet-Draft Internal MIP Handling October 2010
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 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].
Given these mechanisms and the presence of multiple MIPs on a single
node, these mechanisms provide no way to address one particular MIP
out of the set of MIPs on the node.
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
[I-D.ietf-opsawg-mpls-tp-oam-def].
Farrel, et al. Expires April 18, 2011 [Page 4]
Internet-Draft Internal MIP Handling October 2010
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 April 18, 2011 [Page 5]
Internet-Draft Internal MIP Handling October 2010
3. 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.
In-band OAM messages are sent using the G-ACh [RFC5586] and ACH-TLVs
[I-D.ietf-mpls-tp-ach-tlv] 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
Farrel, et al. Expires April 18, 2011 [Page 6]
Internet-Draft Internal MIP Handling October 2010
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 2. 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 2: 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 3, as
well as to handle the optimized P2MP node as shown in Figure 4.
Farrel, et al. Expires April 18, 2011 [Page 7]
Internet-Draft Internal MIP Handling October 2010
--------------------------
| |
| -----|
| | MIP |
| ->-| |->----
| | | Out |
| | | i/f |
| | -----|
|----- | -----|
| MIP | ---- | | MIP |
| | | |- | |
----->-| In |->-| XC |--->-| Out |->----
| i/f | | |- | i/f |
|----- ---- | -----|
| | -----|
| | | MIP |
| | | |
| ->-| Out |->----
| | i/f |
| -----|
--------------------------
Figure 3: Abstract Functional Representation of an MPLS-TP Node
Supporting P2MP
------------------
| |
| ->-|->----
| | |
|------------ | |
| | | |
| MIP ---- | | |
| | | |- |
----->-| In | XC | |--->-|->----
| i/f | | |- |
| ---- | | |
| | | |
|------------ | |
| | |
| ->-|->----
| |
------------------
Figure 4: 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 April 18, 2011 [Page 8]
Internet-Draft Internal MIP Handling October 2010
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.
3.1. Rejected Partial Solution
A reject solution is depicted in Figure 5. 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.
Farrel, et al. Expires April 18, 2011 [Page 9]
Internet-Draft Internal MIP Handling October 2010
------------------------
| |
|----- -----|
local OAM ----->-| MIP |----->------| MIP |
| | ---- | |
data =====>=| In |=>=| XC |=>=| Out |=>==== data
non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
|----- ---- -----|
| |
------------------------
Figure 5: OAM Control Message Delivery Bypassing the Switching Fabric
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.
Note that the local OAM message means that the OAM message which must
be terminated, inspected and processed at the in or out MIP of
depicted MPLS-TP node in Figure 5.
Farrel, et al. Expires April 18, 2011 [Page 10]
Internet-Draft Internal MIP Handling October 2010
4. Proposed Solution
Figure 6 shows a proposed message format for handling the OAM
messages in different cases as described in Section 3. The
subsections that follow describe the processing rules for each case.
Note that this proposed solution could result in a packet with a
TTL=0 to be forwarded. Alternatives are discussed in Section 4.6.
------------------------
|----- -----|
| MIP | ---- | MIP |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
----------------- -------------------
data | Label=x | TTL=n |--------------->| Label=y | TTL=n-1 |
----------------- -------------------
----------------- -------------------
non-local | Label=x | TTL=n |--------------->| Label=y | TTL=n-1 |
OAM |-----------------| |-------------------|
| GAL | TTL=m | | GAL | TTL=m |
|-----------------| |-------------------|
| ACH Type = OAM | | ACH Type = OAM |
----------------- -------------------
-----------------
in-MIP | Label=x | TTL=1 |---
OAM |-----------------| |
| GAL | TTL=m | |
|-----------------| |
| ACH Type = OAM | |
----------------- |
<------
alternative:
-----------------
in-MIP | Label=x | TTL=1 |---
OAM |-----------------| |
| GAL | TTL=m | |
|-----------------| |
| ACH Type = OAM | |
|-----------------| |
| ACH TLV=in-MIP | |
Farrel, et al. Expires April 18, 2011 [Page 11]
Internet-Draft Internal MIP Handling October 2010
----------------- |
<------
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=0 |---
OAM |-----------------| |-----------------| |
| GAL | TTL=m | | GAL | TTL=m | |
|-----------------| |-----------------| |
| ACH Type = OAM | | ACH Type = OAM | |
|-----------------| |-----------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
----------------- ----------------- |
<-------
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=0 |--->
not |-----------------| |-----------------|
supported | GAL | TTL=m | | GAL | TTL=m |
|-----------------| |-----------------|
| ACH Type = OAM | | ACH Type = OAM |
|-----------------| |-----------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
----------------- -----------------
Figure 6: Packet Formats for In and Out MIP OAM in the case of LSPs
------------------------
|----- -----|
| MIP | ---- | MIP |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
----------------- -------------------
data | Label=x | TTL=n |-------------->| Label=y | TTL=n-1 |
----------------- -------------------
------------------ -------------------
non-local | Label=x | TTL=n |------------->| Label=y | TTL=n-1 |
OAM |------------------| |-------------------|
| PWACH Type = OAM | | PWACH Type = OAM |
------------------ -------------------
------------------
in-MIP | Label=x | TTL=1 |---
Farrel, et al. Expires April 18, 2011 [Page 12]
Internet-Draft Internal MIP Handling October 2010
OAM |------------------| |
| PWACH Type = OAM | |
------------------ |
<------
alternative:
------------------
in-MIP | Label=x | TTL=1 |---
OAM |------------------| |
| PWACH Type = OAM | |
|------------------| |
| ACH TLV=in-MIP | |
------------------ |
<------
------------------ ------------------
out-MIP | Label=x | TTL=1 |------------->| Label=y | TTL=0 |---
OAM |------------------| |------------------| |
| PWACH Type = OAM | | PWACH Type = OAM | |
|------------------| |------------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
------------------ ------------------ |
<-------
------------------ ------------------
out-MIP | Label=x | TTL=1 |------------->| Label=y | TTL=0 |--->
not |------------------| |------------------|
supported | PWACH Type = OAM | | PWACH Type = OAM |
|------------------| |------------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
------------------ ------------------
Figure 7: Packet Formats for In and Out MIP OAM in the case of PWs
4.1. Processing of Data and Non-Local OAM
The message formats and processing rules for data and non-local OAM
are not changed by this proposal.
The top-of-stack label is swapped and the top-of-stack TTL is
decremented.
4.2. MIP Identification
[I-D.ietf-mpls-tp-identifiers] defines various identifiers to be used
with MPLS-TP. Using the ACH/PWACH, the MIP identifiers as defined in
[I-D.ietf-mpls-tp-identifiers] can be added as a TLV after the ACH/
PWACH. Both, in- and out-MIPs can therefore unambiguously tell
Farrel, et al. Expires April 18, 2011 [Page 13]
Internet-Draft Internal MIP Handling October 2010
whether an OAM packet is indeed destined to be processed by it.
Various ways to address in- and out-MIPs are conceivable, such as
using the TTL field in the GAL, however, the GAL is only applicable
to LSPs. Furthermore, in case of a P2MP LSP one out of a number of
out-MIPs might need to be uniquely addressed which a TTL field alone
cannot accomplish. Therefore, in order to define a single mechanism
that can be used in all MPLS-TP constructs (PWs, LSPs and P2MP
scenarios) the MIP IDs as defined by [I-D.ietf-mpls-tp-identifiers]
can always be consistently used.
To facilitate an efficient implementation in hardware, the identifier
TLV MUST be in a fixed location after the ACH/PWACH. In case, the
identifier TLV is missing, the in-MIP/or per-nore MIP should process
the packet. This is to ensure compatibility with in-MIP-only/
per-node-MIP-only systems. However, OAM messages which need to
verify the target MIP must contain a TLV that identifies the target
MIP ID as desribed in [I-D.ietf-mpls-tp-identifiers].
4.3. In-MIP Processing
The top-of-stack TTL is decremented and expires. The packet is
examined further and the GAL is discovered indicating that the packet
contains an ACH which needs to be further examined. In case of PWs,
the S bit [RFC3032] is found to be set, and the next nibble is
examined. This shows that a PWACH is present. The Channel Type
field of the PWACH [RFC4385] indicates that the packet is OAM. The
following ACH needs to be further examined.
The ACH type indicates the type of OAM and the the MIP identifier (if
present) can be found in a TLV in a fixed location following the ACH.
In case the ID TLV is not present, the in-MIP (or per-node MIP)
processes that OAM packet.
4.4. Out-MIP Processing
OAM messages intended for the out-MIP on a node are initially
intercepted as described in the previous section. That is, the TTL
expires and further inspection of the packet indicates that it is
OAM.
The incoming interface must forward the OAM message through the
switch fabric as if it was data. The packet is passed on unchanged
except that the TTL has been decremented and expires.
The processing at the out-MIP is comparable to the in-MIP processing.
The TTL has already expired (i.e., is has been decremented to zero at
the incoming interface). If the outgoing interface is capable of
packet inspection, the top- level TTL is found to be zero and the
Farrel, et al. Expires April 18, 2011 [Page 14]
Internet-Draft Internal MIP Handling October 2010
packet is removed from the data stream. In case of LSP OAM, the GAL
is discovered indicating that the packet contains an ACH which needs
to be further examined. In case of PWs, the S bit [RFC3032] is found
to be set, and the next nibble is examined. This shows that a PWACH
is present. The Channel Type field of the PWACH [RFC4385] indicates
that the packet is OAM. The following ACH needs to be further
examined.
The ACH type indicates the type of OAM and the MIP ID TLV (if
present) MUST be in a fixed location following the ACH. Packets not
intended for a given out-MIP are silently discarded. In case there
is no TLV, the out-MIP should discard the packet as the in-MIP should
respond in this case. A per-node MIP should respond.
If the outgoing interface is not capable of packet inspection the
packet will be forwarded out of the outgoing interface. See
Section 4.6 for more details.
4.5. Processing at P2MP Branch Nodes
At P2MP branch nodes, the OAM messages may be targeted at one or all
outgoing interfaces. It should be noted that packet replication is a
function of the switch fabric so that any OAM message forwarded by
the incoming interface will be passed to all outgoing interfaces.
The procedures operate as described before and ACH TLVs are required
to limit the OAM to one or more out-MIPs.
4.5.1. Out-MIP Processing
The outgoing interfaces are able to determine whether the OAM message
is intended for the local out-MIP by examining a MIP identifier
carried in an ACH TLV. There are two potential solutions to this
problem. One could allow more than one MIP identifier to allow
multiple out-MIPs on the same P2MP tree to be targeted by the same
OAM message. This however complicates hardware design as the out-
MIPs need to parse the TLV.
Therefore, instead of having multiple TLVs in a single OAM message,
in case two or more out-MIPs need to be addressed, two or more
messages need to be sent, each carrying the ID TLV identifying the
targeted out-MIP.
A special MIP identifier number is used to indicate that all out-MIPs
on the P2MP PW are targets. This identifier must include an
identifier that is unique to the local node as described in
[I-D.ietf-mpls-tp-identifiers].
An OAM message received at an outgoing interface for a P2MP LSP which
Farrel, et al. Expires April 18, 2011 [Page 15]
Internet-Draft Internal MIP Handling October 2010
does not including any ACH TLVs to identify the out-MIP, should be
silently discarded.
OAM messages received at outgoing interfaces that support out-MIP
OAM, but that are not intended for the local MIP are silently
discarded.
If the outgoing interface is not capable of packet inspection the
packet will be forwarded out of the outgoing interface. See
Section 4.6 for more details.
4.6. Processing When There is No Out-MIP
When there is no out-MIP support on an optimized node implementation
there are three options.
1. The OAM message is intercepted at the incoming interface and the
incoming interface is aware that it forms part of an optimized
implementation that does not support an out-MIP. It can discard
the received OAM message, or respond to indicate that the out-MIP
is not supported.
2. The OAM message is intercepted and forwarded as described in
Section 4.4. Since there is no out-MIP, the message is forwarded
out of the outgoing interface to the next downstream MPLS-TP node
as shown at the bottom of Figures Figure 6 and Figure 7. This
means that the packet will be received at the downstream node
carrying a TTL that has already expired (before it is decremented
at the downstream node) indicating that the packet should be
silently discarded. If the packet is examined in this case, it
will reveal an ACH TLV identifying a MIP that is not local to the
downstream node. This will result in the packet being dropped or
a negative response being sent.
3. The OAM message is intercepted at the incoming interface and this
is a per node MIP which only reacts to TTL expiry (no other
inspection needs to be performed for a per node MIP). In that
case it would process the OAM packet and send a reply if one is
needed. For the MEP receiving the reply there might be no way of
telling that this was send by the incoming MIP.
Farrel, et al. Expires April 18, 2011 [Page 16]
Internet-Draft Internal MIP Handling October 2010
5. Enhanced Proposed Solutions
The above described mechanism has one serious disadvantage, which is
that there are potential situations in which a labeled packet with a
TTL of 0 could be forwarded. This is not standards conformant
behavior. RFC 3032 states:
"If the outgoing TTL of a labeled packet is 0, then the labeled
packet MUST NOT be further forwarded; nor may the label stack be
stripped off and the packet forwarded as an unlabeled packet. The
packet's lifetime in the network is considered to have expired."
As a consequence, there needs to be a way to achieve standard
conformant behavior. The following are proposals to achieve this.
5.1. Incoming MIP Filtering
In Section 4.6, one potential way of handling the case where there is
no outgoing MIP is to make an incoming MIP aware of the MIP
configuration for the maintenance entity it is part of via
configuration. This enables the incoming MIP to make sure that no
labeled packet with a TTL=0 ever leaves the node. It also enables
the MIP to reply to an OAM packet which is addressed to an outgoing
MIP with an error code ('No Such MIP') if desired.
5.2. Outgoing MIP Label
The mechanisms described in Section 4 can be enhanced by the use of a
new reserved label, the Outgoing MIP Label (OML). This label is
substituted for the GAL when an OAM message intended for an outgoing
MIP is processed at an incoming interface as shown in Figure 8.
The advantage of this mechanism is that the outgoing interface of the
local node and the incoming interface of the downstream node have
something more substantial to check than just the TTL value being
zero. In fact, it allows the message to be sent with TTL of one so
that the rules for sending packets with zero TTL are not compromised.
The disadvantage is that a further reserved label is used,
potentially more to cater for the P2MP case.
Note that an option is to allocate the OML as a purely local matter.
That means that the implementation allocates the value of the OML
from its local label space and assigns the meaning as described.
This approach, however, would be risky if the packet escaped and was
processed by the downstream node.
Farrel, et al. Expires April 18, 2011 [Page 17]
Internet-Draft Internal MIP Handling October 2010
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=1 |---
OAM |-----------------| |-----------------| |
| GAL | TTL=m | | OML | TTL=n | |
|-----------------| |-----------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
----------------- ----------------- |
<-------
----------------- -----------------
out-MIP | Label=x | TTL=1 |--------------->| Label=y | TTL=1 |--->
not |-----------------| |-----------------|
supported | GAL | TTL=m | | OML | TTL=n |
|-----------------| |-----------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
----------------- -----------------
Figure 8: Use of the Outgoing MIP Label
Farrel, et al. Expires April 18, 2011 [Page 18]
Internet-Draft Internal MIP Handling October 2010
6. 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.
Farrel, et al. Expires April 18, 2011 [Page 19]
Internet-Draft Internal MIP Handling October 2010
7. IANA Considerations
This revision of this document does not make any requests of IANA.
If the solution described in Section 4 is adopted, a request will be
made to IANA for the allocation of a new reserved label.
Farrel, et al. Expires April 18, 2011 [Page 20]
Internet-Draft Internal MIP Handling October 2010
8. Acknowledgments
TBD
Farrel, et al. Expires April 18, 2011 [Page 21]
Internet-Draft Internal MIP Handling October 2010
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.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[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.
9.2. Informative References
[I-D.ietf-mpls-tp-ach-tlv]
Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., Ward,
D., and V. Manral, "Definition of ACH TLV Structure",
draft-ietf-mpls-tp-ach-tlv-02 (work in progress),
March 2010.
[I-D.ietf-mpls-tp-identifiers]
Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers-02 (work in progress),
July 2010.
[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-09 (work in progress),
October 2010.
[I-D.ietf-opsawg-mpls-tp-oam-def]
Andersson, L., Helvoort, H., Bonica, R., Romascanu, D.,
and S. Mansfield, ""The OAM Acronym Soup"",
draft-ietf-opsawg-mpls-tp-oam-def-06 (work in progress),
June 2010.
[I-D.manral-mpls-tp-oam-security-tlv]
Manral, V., "MPLS-TP General Authentication TLV for
Farrel, et al. Expires April 18, 2011 [Page 22]
Internet-Draft Internal MIP Handling October 2010
G-ACH", draft-manral-mpls-tp-oam-security-tlv-00 (work in
progress), June 2009.
Farrel, et al. Expires April 18, 2011 [Page 23]
Internet-Draft Internal MIP Handling October 2010
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
Farrel, et al. Expires April 18, 2011 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-23 09:15:50 |