Internet DRAFT - draft-ietf-mpls-tp-mip-mep-map

draft-ietf-mpls-tp-mip-mep-map






Network Working Group                                          A. Farrel
Internet-Draft                                          Juniper Networks
Intended status: Informational                                   H. Endo
Expires: March 3, 2014                                     Hitachi, Ltd.
                                                               R. Winter
                                                                     NEC
                                                                Y. Koike
                                                                     NTT
                                                                 M. Paul
                                                        Deutsche Telekom
                                                         August 30, 2013


  Per-Interface MIP Addressing Requirements and Design Considerations
                   draft-ietf-mpls-tp-mip-mep-map-09

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 elaborates on important considerations for internal MIP
   addressing.  More precisely it describes important restrictions for
   any mechanism that specifies a way of forming OAM messages so that
   they can be targeted at MIPs on incoming or MIPs on outgoing
   interfaces and forwarded correctly through the forwarding engine.
   Furthermore, the document includes considerations for node
   implementations where there is no distinction between the incoming
   and outgoing MIP.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 3, 2014.



Farrel, et al.            Expires March 3, 2014                 [Page 1]

Internet-Draft         Internal MIP Considerations           August 2013


Copyright Notice

   Copyright (c) 2013 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Summary of the Problem Statement . . . . . . . . . . . . . . .  3
   4.  Requirements and Design Considerations for Internal-MIP
       Adressing  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11





















Farrel, et al.            Expires March 3, 2014                 [Page 2]

Internet-Draft         Internal MIP Considerations           August 2013


1.  Introduction

   The Framework for Operations, Administration and Maintenance (OAM)
   within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM
   Framework, [RFC6371]) 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 each side 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] or the presence of
   a GAL [RFC6423].

   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.  A mechanism that addresses this shortcoming has to obey a few
   important design considerations which are discussed in this document.

   Note that the acronym "OAM" is used in conformance with [RFC6291].


2.  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.  The term
   "forwarding engine" is used as defined in [RFC6371].


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 forwarding engine



Farrel, et al.            Expires March 3, 2014                 [Page 3]

Internet-Draft         Internal MIP Considerations           August 2013


   (FW), and an outgoing interface.  As per the discussion in [RFC6371],
   MIPs may be placed in each of the functional interface components.

                         ------------------------
                        |-----              -----|
                        | MIP |            | MIP |
                        |     |    ----    |     |
                 ----->-| In  |->-| FW |->-| 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 for both PWs and LSPs such as:

   o  Connectivity Verification (CV) between a MEP and a MIP
   o  traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing
      MIPs
   o  data-plane loopback configuration 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 diagnostic
   tests.  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-node MIPs and MEPs.  For reasons of exposition
   we pick a location for the MIPs on the nodes but the standard does
   not mandate the exact location for the per-node model.  In the figure
   a bi-directional LSP is depicted where in the forward (FWD) direction
   MEP1, MIP1, and MEP2 are located on the ingress interface (IF).  In
   the backward (BWD) direction MEP1', MIP1' and MEP2' are located on
   the egress IF, i.e. the same interfaces.  S1 in the figure denotes
   the segment from PE1 In to P1 In and S2 denotes the segment from PE1
   In to P2 In.  Figure 3 on the other hand shows the same basic network
   but for OAM operations per-interface maintenance points are
   configured.  Note that these figures are merely examples.  It is
   important to note that per-interface MEPs or per-interface MIPs must



Farrel, et al.            Expires March 3, 2014                 [Page 4]

Internet-Draft         Internal MIP Considerations           August 2013


   logically be placed at a point before (for in-MIP) or after (for out-
   MIP) passing the forwarding engine as defined in [RFC6371].  All
   traffic associated with the MEP/MIP must pass through or be
   terminated at that point.



      Customer|           Operator's administrative     | Customer
      Domain  |           Domain                        | Domain
      ------> |<--------------------------------------->| <------
        CE1   |   T-PE/PE1      S-PE/P1        T-PE/PE2 |   CE2
              |  <-------->    <-------->    <--------> |
       +---+  | +-+ +-+ +-+   +-+ +-+ +-+   +-+ +-+ +-+ |  +---+
       |   |  | | | | | | |   | | | | | |   | | | | | | |  |   |
       |   |  | | | | | | |   | | | | | |   | | | | | | |  |   |
       +---+  | +-+ +-+ +-+   +-+ +-+ +-+   +-+ +-+ +-+ |  +---+
              | In  FW  Out   In  FW  Out   In  FW  Out |
              |                                         |
   FWD PW/LSP |  o-------------------------- >          |
              |  V-------------*-------------V          |
              | MEP1          MIP1          MEP2        |
   BWD PW/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.  Note that in this
   scenario, the PWs or LSPs are to be understood as two examples (not
   one).  I.e. the figures do not show the layer structure of PWs and
   LSPs.

   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



Farrel, et al.            Expires March 3, 2014                 [Page 5]

Internet-Draft         Internal MIP Considerations           August 2013


   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
   which gives operators better information to deal with adverse
   networking conditions.



      Customer           Operator's administrative       Customer
      Domain             Domain                          Domain
      ------->|<--------------------------------------->|<------
        CE1   |   T-PE/PE1      S-PE/P1       T-PE/PE2  |   CE2
              |  <-------->    <-------->    <--------> |
       +---+  | +-+ +-+ +-+   +-+ +-+ +-+   +-+ +-+ +-+ |  +---+
       |   |  | | | | | | |   | | | | | |   | | | | | | |  |   |
       |   |  | | | | | | |   | | | | | |   | | | | | | |  |   |
       +---+  | +-+ +-+ +-+   +-+ +-+ +-+   +-+ +-+ +-+ |  +---+
              | In  FW  Out   In  FW  Out   In  FW  Out |
              |                                         |
   FWD PW/LSP |  o----------------------------------->  |
              |  V-------*------*------*-----*-------V  |
              | MEP1    MIP1   MIP2   MIP3  MIP4    MEP2|
              |                                         |
   BWD PW/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


4.  Requirements and Design Considerations for Internal-MIP Adressing

   OAM messages for 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.  These messages 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] or the presence of a GAL [RFC6423].  In addition,
   two sets of identifiers exist that can be used to address MIPs which
   are defined in [RFC6370] and [RFC6923]



Farrel, et al.            Expires March 3, 2014                 [Page 6]

Internet-Draft         Internal MIP Considerations           August 2013


   Any solution for sending OAM messages to the in and out-MIPs must fit
   within these existing models of handling OAM.

   Additionally, many MPLS-TP nodes are implemented in a way 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 messages to the outgoing
   interface of an MPLS-TP node must not cause any problems when such
   implementations are present (such as leaking OAM packets with a TTL
   of 0).


                             ---------------------
                            |------------         |
                            | MIP        |        |
                            |      ----  |        |
                     ----->-| In  | FW | |-->-Out-|->---
                            | i/f  ----  |    i/f |
                            |------------         |
                             ---------------------

   Figure 4: Abstract Functional Representation of Some Existing MPLS-TP
                                   Nodes

   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 well as to
   handle the P2MP node implementations as shown in Figure 6 without
   causing problems.
















Farrel, et al.            Expires March 3, 2014                 [Page 7]

Internet-Draft         Internal MIP Considerations           August 2013


                         --------------------------
                        |                     -----|
                        |                    | MIP |
                        |                 ->-|     |->----
                        |                |   | Out |
                        |                |   | i/f |
                        |                |    -----|
                        |-----           |    -----|
                        | MIP |    ----  |   | MIP |
                        |     |   |    |-    |     |
                 ----->-| In  |->-| FW |--->-| Out |->----
                        | i/f |   |    |-    | i/f |
                        |-----     ----  |    -----|
                        |                |    -----|
                        |                |   | MIP |
                        |                |   |     |
                        |                 ->-| Out |->----
                        |                    | i/f |
                        |                     -----|
                         --------------------------

      Figure 5: Abstract Functional Representation of an MPLS-TP Node
                              Supporting P2MP


                           ----------------------
                          |               ->-Out-|->----
                          |              |   i/f |
                          |------------  |       |
                          |            | |       |
                          | MIP  ----  | |       |
                          |     |    | |-        |
                   ----->-| In  | FW | |--->-Out-|->----
                          | i/f |    | |-    i/f |
                          |      ----  | |       |
                          |            | |       |
                          |------------  |       |
                          |              |   Out |
                          |               ->-i/f-|->----
                           ----------------------

   Figure 6: Abstract Functional Representation of Some Existing MPLS-TP
                           Nodes Supporting P2MP

   In summary, the solution for OAM message delivery must behave as
   follows:





Farrel, et al.            Expires March 3, 2014                 [Page 8]

Internet-Draft         Internal MIP Considerations           August 2013


   o  Delivery of OAM messages to the correct MPLS-TP node.
   o  Delivery of OAM instructions to the correct MIP within an MPLS-TP
      node.
   o  Forwarding of OAM packets exactly as data packets.
   o  Packet inspection at the incoming and outgoing interfaces must be
      minimized.

   The first and second bullet point are obvious.  The third bullet
   point however is also vital.  To illustrate the importance, a
   rejected solution is depicted in Figure 7.  In the figure, 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  |=>=| FW |=>=| Out |=>==== data
     non-local OAM ~~~~~>~| i/f |~>~|    |~>~| i/f |~>~~~~ non-local OAM
                          |-----     ----     -----|
                           ------------------------

      Figure 7: OAM Control Message Delivery Bypassing the Forwarding
                                  Engine

   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
   forwarding engine, this solution cannot correctly perform OAM
   loopback, connectivity verification, LSP tracing, or performance
   measurement.

   The last bullet point is also an important requirement for any
   solution to the internal-MIP addressing problem.  Since OAM packets
   that target an out-MIP need to be sent through the forwarding engine
   and treated exactly as regular data packets, the determination of
   whether to forward the packet or process it at the incoming MIP needs
   to be fast and therefore the processing overhead must be kept to a
   minimum.  In addition, there are a few OAM procedures that operate at
   line rate such as OAM loopback.  This adds to the requirement of



Farrel, et al.            Expires March 3, 2014                 [Page 9]

Internet-Draft         Internal MIP Considerations           August 2013


   minimal processing overhead for both the in-MIP and out-MIP.

   Most of the above superficially appears to be an implementation
   matter local to an individual node, the format of the message needs
   to be standardised so that:

   o  A MEP can correctly target the outgoing MIP of a specific MPLS-TP
      node.
   o  A 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
      implementation as shown in Figure 4 or Figure 6.

   Note that the last bullet point describes a safety net and an
   implementation should avoid that this situation ever arises.


5.  Security Considerations

   OAM security is discussed in [RFC6371] and security aspects specific
   to MPLS-TP in general are outlined in [RFC6941].

   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.


6.  IANA Considerations

   This revision of this document does not make any requests of IANA.


7.  Acknowledgments

   The authors gratefully acknowledge the substantial contributions of
   Zhenlong Cui. We would also like to thank Eric Gray, Sami Boutros and
   Shahram Davari for interesting input to this document through
   discussions.


8.  References



Farrel, et al.            Expires March 3, 2014                [Page 10]

Internet-Draft         Internal MIP Considerations           August 2013


8.1.  Normative References

   [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.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.

   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
              Maintenance Framework for MPLS-Based Transport Networks",
              RFC 6371, September 2011.

   [RFC6423]  Li, H., Martini, L., He, J., and F. Huang, "Using the
              Generic Associated Channel Label for Pseudowire in the
              MPLS Transport Profile (MPLS-TP)", RFC 6423,
              November 2011.

   [RFC6923]  Winter, R., Gray, E., van Helvoort, H., and M. Betts,
              "MPLS Transport Profile (MPLS-TP) Identifiers Following
              ITU-T Conventions", RFC 6923, May 2013.

8.2.  Informative References

   [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.

   [RFC6941]  Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
              Graveman, "MPLS Transport Profile (MPLS-TP) Security
              Framework", RFC 6941, April 2013.


Authors' Addresses

   Adrian Farrel
   Juniper Networks

   Email: adrian@olddog.co.uk









Farrel, et al.            Expires March 3, 2014                [Page 11]

Internet-Draft         Internal MIP Considerations           August 2013


   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
   Deutsche Telekom

   Email: Manuel.Paul@telekom.de





























Farrel, et al.            Expires March 3, 2014                [Page 12]