\
MPLS Working Group                                        R. Raszuk, Ed.
Internet-Draft                                                    NTT NI
Intended status: Informational                             25 April 2022
Expires: 27 October 2022


            Framework of MPLS Reference Augmented Forwarding
                      draft-raszuk-mpls-raf-fwk-00

Abstract

   This document specifies an architectural framework for enabling MPLS
   based forwarding with optional reference based packet processing in
   transit network elements.

Requirements Language

   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 RFC 2119 [RFC2119].

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 https://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 27 October 2022.

Copyright Notice

   Copyright (c) 2022 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 (https://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



Raszuk                   Expires 27 October 2022                [Page 1]


Internet-Draft                  MPLS RAF                      April 2022


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Processing  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Reference to Special Instructions Mapping . . . . . . . . . .   5
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
   7.  Capability Advertisement  . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Growth of network services results in increased demand for custom
   transit packet processing.  Traditional per destination based best
   effort or constrained based forwarding is no longer sufficient.  Hop
   by hop switching in addition to label or destination based LSP
   switching can be augmented with additional packet processing at all
   or at selective transit network elements.

   Such additional processing can be triggered in a number of ways.
   Today some networks can apply local policies which enable selective
   processing on subset of packets based on the header's elements.
   Alternative to such filtering is to embed additional information in
   the packet header itself to indicate implicitly or explicitly what
   additional processing is required.

   Examples of explicit encoding of such network actions can be found in
   SRv6 Network Programming [RFC8986] document.  For MPLS data plane an
   analogy to SRv6 has been recently proposed in
   draft-andersson-mpls-mna-fwk [I-D.andersson-mpls-mna-fwk].








Raszuk                   Expires 27 October 2022                [Page 2]


Internet-Draft                  MPLS RAF                      April 2022


   In this document authors propose an implicit model.  Instead of
   explicitly encoding all required actions as a variable size ordered
   list in every packet this document proposes to insert fixed size 20
   bit reference identifier.  Such value will be used to mark groups of
   flows with identical custom forwarding behaviour.

   By forwarding behaviour (further abbreviated as FB) this document
   assumes additional network actions which may exclude packet from
   default processing, may include additional security screening, OAM
   triggering actions or any other special handling including, but not
   limited to rate limited, queue mapping, redirection etc ...

2.  Terminology

2.1.  Definitions

   *  Network Action aka Forwarding Behaviour: An operation to be
      performed on a packet or be triggered based on given packet's
      arrival without affecting the packet switching decision.  A
      network action may affect forwarding decisions, queuing
      classification, OAM measurement and reporting etc .... Network
      Actions are not carried in packets.  They are distributed by
      configuration or control plane.

   *  Reference Augmented Forwarding: Packet forwarding in addition to
      or instead of normal lookup (by address or label) based on a set
      of Network Actions or Forwarding Behaviours indicated by Reference
      Identifier.

   *  Reference Forwarding Value: A 20 bit value carried in a packet
      used to identify a set of Network Actions defining given packet's
      special handling.

   *  Reference Forwarding Indicator: A base Special Purpose Label
      carried in a packet used to indicate to the packet processor that
      the following LSE is containing Reference Forwarding Value.

2.2.  Abbreviations

   *  FB - Network Actions or Forwarding Behaviours

   *  LSE - Label Stack Entry

   *  RAF - Reference Augmented Forwarding

   *  bSPL - Base Special Purpose Label

   *  ECMP - Equal Cost Multipath



Raszuk                   Expires 27 October 2022                [Page 3]


Internet-Draft                  MPLS RAF                      April 2022


   *  RFI - Reference Forwarding Indicator

   *  RFV - Reference Forwarding Value

   *  TBA - To Be Allocated

   *  SDN - Software Defined Network

3.  Encoding

   A Reference Forwarding Value MUST be clearly distinguished from any
   forwarding label.  LSE immediately preceding label stack entry
   containing RFV is called Reference Forwarding Indicator.  RFI is
   REQUIRED to use Special Purpose Label value (TBA by IANA).

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               RFI - bSPL              | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  RFV                  | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  RFI:    Reference Forwarding Indicator, 20 bits
                  RFV:    Reference Forwarding Value, 20 bits
                  TC:     Traffic Class, 3 bits
                  S:      Bottom of Stack, 1 bit
                  TTL:    Time To Live

                        Figure 1: RFI and RFV Tuple

   RFI and RFV tuple is always of fixed size of 8 octets.  It also
   should occur only once in a given packet.  It is optional.  If a
   network uses the concept of LSPs it MUST be placed after the topmost
   label.  If LSP is not setup and the network uses the concept of SDN
   based path computation it can be preset as topmost LSE.

   How to set values of the TTL, TC, and Bottom of Stack (S bit) fields
   [RFC3032] for the RFI and RFV entries should be the same as described
   in [RFC6790] Section 4.2.  Ingress LSR SHOULD put the same TTL and TC
   fields for the RFI as it does for transport label.  Such ingress LSR
   MAY choose different values for the TTL and TC fields if it is known
   that the RFI will not be exposed as the top label at any point along
   the LSP (as may happen in cases where PHP is used and the RFI and RFV
   are not stripped at the penultimate hop.  The BoS bit for the RFI
   MUST be set to zero (i.e., BoS is not set).  The TTL for the RFV MUST
   be zero to ensure that it is not used inadvertently for forwarding.
   The TC for the RFV may be any value.  The BoS bit for the RFV depends
   on whether or not there are more labels in the label stack.



Raszuk                   Expires 27 October 2022                [Page 4]


Internet-Draft                  MPLS RAF                      April 2022


4.  Processing

   Any network element can insert, delete or modify RFV or RFI-RFV tuple
   if instructed to do so by special action instructions.

   If a network element understands RFI and recognizes based on the top
   most lable value special handling requirement it MAY direct packet
   for special processing.  MAY or MUST processing of all requested
   actions (or subset of those actions) really depend on the special
   action instructions.

5.  Reference to Special Instructions Mapping

   As the proposed architecture is based on indirection, what is present
   in the packet is only a reference to special handling instructions.
   Such instructions are not to be explicitly carried in the packet.  As
   each network operator has a different set of operational preferences,
   embedding insertion of actions into a data plane parsing of each
   packet is very operationally limiting and inefficient.

   Special Network Actions or Forwarding Behaviours are to be
   distributed by configuration or by control plane.  Details of their
   distribution are outside of scope of this framework document.
   However, it is important to recognize that this model in its roots
   allows open innovation for vendors in developing accelerated data
   plane action dictionaries as mapping and execution has only a local
   scope.

   It needs to be further observed that format of such configuration or
   control plane (including PUB-SUB model) distributed Forwarding
   Behaviours MAY have a TLV/sub-TLV structure as illustrated on
   Figure 2 and 3 below:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |    Flags      |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          DST NODE ID(s)                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              RFV                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Sub-TLV(s)                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Figure 2: FB TLV





Raszuk                   Expires 27 October 2022                [Page 5]


Internet-Draft                  MPLS RAF                      April 2022


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+
    |     Type      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Special Actions and Optional Ancillary Data (variable)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 3: FB sub-TLV

   With such encoding option it needs to be observed that for a given
   RFV only nodes listed in the TLV will accept and install special
   handling instructions.

6.  Operational Considerations

   The proposed model is designed to operate both in the networks using
   traditional MPLS LSP (with local labels) as well with SR-MPLS (domain
   wide labels).

   Nodes which utilize MPLS LSPs and did not receive any special
   handling instructions via control plane are NOT REQUIRED to inspect
   anything above the top label and will continue to perform basic label
   switching.  If a node is enabled to perform additional actions on the
   packets it should leave the RFI/RFV tuple as received immediately
   after the top label swap on the stack.  The PHP action may take place
   as usuall exposing RFI LSE.  In such cases egress LSR MUST be able to
   understand bSPL and either discard RFI/RFV tuple or if configured so
   execute special actions on those packets before further forwarding
   it.

   [Discussion point for WG: Should nodes inserting additional labels on
   the stack for example during FRR should copy the RFI/RFV to enable it
   to be executed on the repair path or not ?].

   Nodes which utilize the concept of SR-MPLS and use global labels as a
   replacement for use of LDP can apply the same set of procedures as
   nodes using MPLS-LSP.

   Nodes which utilize the concept of SR-MPLS and use global labels with
   segment endpoints encoded in the label stack MUST understand RFI bSPL
   in order to correctly copy the tuple to always place it immediately
   behind the top most segment endpoint during label stack modification.






Raszuk                   Expires 27 October 2022                [Page 6]


Internet-Draft                  MPLS RAF                      April 2022


   To further simplify the concept of MPLS RAF deployment networks which
   utilize concept of domain wide labels can allocate two label values
   from each LSR.  One would indicate non RAF forwarding and the other
   one RAF enhanced forwarding.  With such allocation only nodes which
   recognize that arriving packets contain RAF aware label value and
   which received any special handling instructions may need to perform
   additional RFI/RFV lookup and processing.  Such allocation may be
   unified to differentiate normal vs RAF enabled labels with common
   label block offset or selected label bit set.

7.  Capability Advertisement

   This document does not require any new capability to be defined.

8.  IANA Considerations

   This document defines a new bSPL label called Reference Forwarding
   Indicator and is requesting IANA to allocate one from Base Special-
   Purpose MPLS Label Values registry.

9.  Security Considerations

   This document does not introduce any new security risks.

10.  Acknowledgements

   Author would like to thank Tony Li and Jeff Tantsura for encouraging
   me to write this up.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.




Raszuk                   Expires 27 October 2022                [Page 7]


Internet-Draft                  MPLS RAF                      April 2022


11.2.  Informative References

   [I-D.andersson-mpls-mna-fwk]
              Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS
              Network Actions Framework", Work in Progress, Internet-
              Draft, draft-andersson-mpls-mna-fwk-00, 4 April 2022,
              <https://www.ietf.org/archive/id/draft-andersson-mpls-mna-
              fwk-00.txt>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

Author's Address

   Robert Raszuk (editor)
   NTT NI
   Email: robert@raszuk.net































Raszuk                   Expires 27 October 2022                [Page 8]