One document matched: draft-farrel-mpls-tp-mip-mep-map-00.txt
Network Working Group A. Farrel
Internet-Draft Huawei Technologies
Intended status: Standards Track
Expires: May 29, 2010 November 29, 2009
Handling MPLS-TP OAM Packets Targeted at Internal MIPs
draft-farrel-mpls-tp-mip-mep-map-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 1]
Internet-Draft Internal MIP Handling November 2009
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 incoming MIPs and outgoing MIPs, forwarded
correctly through the "switch fabric", and handled efficiently in
optimized 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.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 2]
Internet-Draft Internal MIP Handling November 2009
1. Introduction
The Framework for Operations, Administration and Maintenance (OAM)
within the MPLS Transport Profile (MPLS-TP) (the MPLS-TP OAM
Framework, [OAM-FWK]) describes how Maintenance Intermediate Points
(MIPs) may be situated within network nodes at the incoming and
outgoing interfaces.
OAM messages are formed and delivered using the expiration of the
MPLS shim header time-to-live (TTL) field, and the presence of the
Generic Associated Channel Label (GAL) in the label stack under the
top label [RFC5586]. This means that all OAM messages intended for
any MIP on a node are delivered to the MIP at the incoming interface.
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
optimized 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.
Note that the acronym "OAM" is used in conformance with [OAM-SOUP].
2. Summary of Problem Statement
Figure 1 shows an abstract functional represenation 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
[OAM-FWK], MIPs may be placed in each of the functional interace
components.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 3]
Internet-Draft Internal MIP Handling November 2009
------------------------
| |
|----- -----|
| 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:
- OAM loopback at a MIP
- data loopback at a MIP
- OAM control at a MIP
- measurement at a MIP
The MIPs in these OAM functions may equally be the MIPs at the input
or output interfaces.
The way that OAM messages are delivered to an MPLS-TP node is through
the expirey of the TTL in the top-of-stack shim header on the MPLS
packet. The top label in the stack is always the same as would be
used for data on the same label switched path (LSP) so that OAM is
handled in exactly the same way as data as it travels through the
network. The second label on the stack is the GAL so that OAM can be
distinguished from data.
Any solution for sending OAM to the in and out MIPs must fit within
this existing model of handling OAM.
Additionally, many MPLS-TP nodes contain an optimization such that
all queuing and 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
function on those interfaces. This is particularly the case for
existing deployed implmentations.
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.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 4]
Internet-Draft Internal MIP Handling November 2009
------------------
| |
|------------ |
| 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). That means that it must possible to
target individual outgoing MIPs as well as all outgoing MIPs in the
abstract fucntional representation shown in Figure 3, as well as to
handle the optimized P2MP node as shown in Figure 4.
--------------------------
| |
| -----|
| | 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
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 5]
Internet-Draft Internal MIP Handling November 2009
------------------
| |
| ->-|->----
| | |
|------------ | |
| | | |
| 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
following features:
- Forwarding of OAM packets exactly as data packets.
- Delivery of OAM messages to the correct MPLS-TP node.
- Direction of OAM instructions to the correct MIP within an MPLS-TP
node.
- Packet inspection at the outgoing interface must be minimised.
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:
- An upstream MEP can correctly target the outgoing MIP of a specific
MPLS-TP node.
- A downstream node can correctly filter out any OAM messages that
were intended for its upstream negihbor's outgoing MIP, but which
were not handled there because the upstream neighbor is an
optimized implmentation.
2.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
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 6]
Internet-Draft Internal MIP Handling November 2009
issues. 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 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 the OAM message is not forwarded through the
switch fabric, this solution cannot correctly perform OAM loopback,
connectivity verification, LSP tracing, or performance measurement.
3. Proposed Solution
Figure 6 shows a proposed message format for handling the different
cases described in Section 2. The subsections that follow describe
the processing rules for each case.
Note that this proposed solution requires a packet to be sent with
TTL=0. An alternative approach is described in Section 4.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 7]
Internet-Draft Internal MIP Handling November 2009
------------------------
|----- -----|
| MIP | ---- | MIP |
----->-| In |->-| XC |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
----------------- -------------------
data | Label=x | TTL=n |----------------->| Label=y | TTL=n-1 |
----------------- -------------------
----------------- -----------------
non-local| Label=x | TTL=2 |----------------->| Label=y | TTL=1 |
OAM|-----------------| |-----------------|
| GAL | | | GAL | |
|-----------------| |-----------------|
| ACH Type = OAM | | ACH Type = OAM |
----------------- -----------------
-----------------
in-MIP| Label=x | TTL=1 |---
OAM|-----------------| |
| GAL | | |
|-----------------| |
| ACH Type = OAM | |
----------------- |
<------
----------------- -----------------
out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=0 |---
OAM|-----------------| |-----------------| |
| GAL | | | GAL | | |
|-----------------| |-----------------| |
| 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 | | | GAL | |
|-----------------| |-----------------|
| ACH Type = OAM | | ACH Type = OAM |
|-----------------| |-----------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
----------------- -----------------
Figure 6 : Packet Formats for In and Out MIP OAM
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 8]
Internet-Draft Internal MIP Handling November 2009
3.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.
3.2. Processing of In-MIP OAM
The message formats and processing rules for in-MIP OAM are not
changed by this proposal.
The top-of-stack TTL is decremented and expires. The packet is
examined further and the GAL is discovered. Further inspection of the
packet reveals the ACH type and the packet is delivered to the
in-MIP.
Note that an ACH TLV could be included to identify the in-MIP (as in
Section 3.3), but this is not required since the absence of such a
TLV could be inferred to indicate the in-MIP as the target.
3.3. Processing of Out-MIP OAM
OAM messages intended for the out-MIP on a node are initially
intercepted as any OAM message targeted at any MIP on the node. That
is, the TTL expires, the GAL is found, and the ACH indicates that the
message is OAM.
An ACH TLV is included to indicate that the OAM is targeted at the
outgoing MIP.
The incoming interface must forward the OAM message through the
switch fabric as if it was data. So, the packet is passed on
unchanged except that the TTL has been decremented and expired. This
enables the outgoing interface to inspect only the TTL field of the
outgoing packet to know that it should intercept the packet and not
send it out to the next MPLS-TP node.
Further inspection of the packet at the outgoing interface will
reveal the GAL, the ACH type, and the ACH TLV.
3.4. 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.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 9]
Internet-Draft Internal MIP Handling November 2009
The procedures operate as described in section 3.3. The outgoing
interfaces are able to determine whether the OAM message is intended
for the local MIP by examining a MIP identifier carried in an ACH
TLV.
OAM messages received at outgoing interfaces but not intended for the
local MIP are silently dropped.
3.5. Processing When There is No Out-MIP
When there is no out-MIP supported on an optimized switch
implementation there are two options.
1. The OAM message is intercepted at the incoming interface as
described in Section 3.3, but 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 3.3. 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 Figure 6. 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, it will reveal a GAL, an ACH type
indicating OAM, and 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.
4. Enhanced Proposed Solution
The mechanisms described in Section 3 can be enhanced by the use of a
new reserved label, the Outgoin Mip Lable (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 7.
The advantage of this mechanism is that the outgoing interface of the
local node and the incoming interface of the downstream node have
someting more substantial to check than just the TTL value being
zero. In fact, it allows the mesage 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.
Note that an option is to allocate the OML as a purely local matter.
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 10]
Internet-Draft Internal MIP Handling November 2009
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.
----------------- -----------------
out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=1 |---
OAM|-----------------| |-----------------| |
| GAL | | | OML | | |
|-----------------| |-----------------| |
| ACH TLV=out-MIP | | ACH TLV=out-MIP | |
----------------- ----------------- |
<-------
----------------- -----------------
out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=1 |--->
not |-----------------| |-----------------|
supported| GAL | | | OML | |
|-----------------| |-----------------|
| ACH TLV=out-MIP | | ACH TLV=out-MIP |
----------------- -----------------
Figure 7 : Use of the Outgoing MIP Label
5. Security Considerations
OAM security is discussed in [OAM-FWK] and [OAM-SEC].
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. Implementations are required to offer security
mechanisms for OAM. Deployments are strongly advised to use suh
mechanisms.
6. 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.
7. Acknowledgment
TBD
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 11]
Internet-Draft Internal MIP Handling November 2009
8. References
8.1. Normative References
[RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic
Associated Channel", RFC 5586, June 2009.
8.2. Informative References
[OAM-FWK] Busi, I., Niven-Jenkins, B. and Allan, D., "MPLS-TP OAM
Framework ", draft-ietf-mpls-tp-oam-framework, work in
progress.
[OAM-SOUP] Andersson, L., Betts, M., van Helvoort, H., Bonica, R.,
and Romascanu, D., "The OAM Acronym Soup", draft-ietf-
opsawg-mpls-tp-oam-def, work in progress.
[OAM-SEC] Manral, V., "MPLS-TP General Authentication TLV for
G-ACH", draft-manral-mpls-tp-oam-security-tlv, work in
progress.
Author's Address
Adrian Farrel
Huawei Technologies
Email: adrian.farrel@huawei.com
Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 09:51:14 |