Internet DRAFT - draft-shrivastava-ospf-flow-spec

draft-shrivastava-ospf-flow-spec







Network Working Group                                     R. Shrivastava
Internet-Draft                                              M. Dubrovsky
Intended status: Standards Track                                K. Patel
Expires: October 19, 2013                                   B. Pithawala
                                                           Cisco Systems
                                                          April 17, 2013


             Flow Specification Extensions to OSPF Protocol
                  draft-shrivastava-ospf-flow-spec-01

Abstract

   This document describes the extensions to the OSPF protocol to
   distribute the traffic flow specification rules and associated
   actions.  The notion and principles of operation of the mechanism
   were initially introduced into the BGP protocol.  The IPv4 part of
   specification was published in RFC5575 and later the specification
   was enhanced for IPv6 via draft-raszuk-idr-flow-spec-v6.  The
   mechanism allows the routing protocol to distribute information about
   the traffic flows and associated actions such as packet filtering
   with it.

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 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 October 19, 2013.

Copyright Notice




Shrivastava, et al.     Expires October 19, 2013                [Page 1]

Internet-Draft          OSPF Flow Specification               April 2013


   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.  The Flow Specification Operation Description  . . . . . . . .   4
     2.1.  The Flow Specification Origins  . . . . . . . . . . . . .   4
     2.2.  Flow-specification-LSA scope and re-origination . . . . .   4
     2.3.  IPv4 and IPv6 rules . . . . . . . . . . . . . . . . . . .   4
   3.  OSPFv2 Flow-specification-LSA . . . . . . . . . . . . . . . .   5
     3.1.  Link-State ID format  . . . . . . . . . . . . . . . . . .   5
   4.  OSPFv3 Flow-specification-LSA . . . . . . . . . . . . . . . .   5
   5.  Flow-specification-LSA payload  . . . . . . . . . . . . . . .   6
   6.  IPv4 Flow Specification . . . . . . . . . . . . . . . . . . .   6
     6.1.  Destination Prefix TLV  . . . . . . . . . . . . . . . . .   7
     6.2.  Source Prefix TLV . . . . . . . . . . . . . . . . . . . .   7
     6.3.  IP Protocol . . . . . . . . . . . . . . . . . . . . . . .   7
     6.4.  Port  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.5.  Destination port  . . . . . . . . . . . . . . . . . . . .   7
     6.6.  Source port . . . . . . . . . . . . . . . . . . . . . . .   8
     6.7.  ICMP Type . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.8.  ICMP code . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.9.  TCP flags . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.10. Packet length . . . . . . . . . . . . . . . . . . . . . .   8
     6.11. DSCP (Diffserv Code Point)  . . . . . . . . . . . . . . .   8
     6.12. Fragment  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IPv6 Flow Specification . . . . . . . . . . . . . . . . . . .   9
     7.1.  Destination IPv6 Prefix TLV . . . . . . . . . . . . . . .   9
     7.2.  Source IPv6 Prefix TLV  . . . . . . . . . . . . . . . . .  10
     7.3.  Traffic Class . . . . . . . . . . . . . . . . . . . . . .  10
     7.4.  Flow Label  . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  IPv4 Traffic Filtering Actions  . . . . . . . . . . . . . . .  10
     8.1.  Traffic-rate  . . . . . . . . . . . . . . . . . . . . . .  11
     8.2.  Traffic-action  . . . . . . . . . . . . . . . . . . . . .  11
     8.3.  Redirect  . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.4.  Traffic-marking . . . . . . . . . . . . . . . . . . . . .  11
   9.  IPv6 Traffic Filtering Actions  . . . . . . . . . . . . . . .  12



Shrivastava, et al.     Expires October 19, 2013                [Page 2]

Internet-Draft          OSPF Flow Specification               April 2013


     9.1.  Traffic-marking . . . . . . . . . . . . . . . . . . . . .  12
   10. Order of Traffic Filtering Rules  . . . . . . . . . . . . . .  12
   11. Validation Procedure  . . . . . . . . . . . . . . . . . . . .  12
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This document describes a method of adding capability to distribute
   traffic flow specification rules into OSPF.

   The semantic content of the extensions is identical to the
   corresponding extensions to BGP ([BGP-FLOWSPEC] and
   [draft-raszuk-idr-flow-spec-v6]).  In order to avoid repetition, this
   document only concentrates on those parts of specification where OSPF
   is different from BGP.

   Each flow specification rules is encapsulated into the flow-
   specification-LSA and then flooded along with the prefix reachability
   information across an area or the entire OSPF routing domain.  When a
   router receives the LSA from its neighbor, it decodes the data,
   validates the information and applies the filtering rules as defined.

   Some OSPF routers can be configured to originate flow specification
   rules with associated actions.  Other routers can be configured to
   apply these rules from specific sets of OSPF Router IDs.

   The use cases for the traffic policy mechanism are different from the
   BGP.  Let's look at some examples.

   Example : Installation of a new voice gateway in the enterprise
   network.

   The router, which is directly connected to the new voice gateway,
   originates flow specification rules that describe voice traffic and
   set QoS marking action.  Routers on the other side of the WAN links
   are configured to act on this information.

   Another example: temporarily contractors.









Shrivastava, et al.     Expires October 19, 2013                [Page 3]

Internet-Draft          OSPF Flow Specification               April 2013


   The contractor company, which is connected to the enterprise network
   via the WAN link, should have limited access to certain servers.  The
   routers directly connected to the corporate data center can originate
   rules describing services accessibility for contractors.  The edge
   routers with WAN links to the contractor's equipment install those
   rules to block the undesirable traffic.

   Last example: Service provider MPLS VPN hub-and-spoke solution for
   the enterprise customer.

   The spokes are connected to the MPLS VPN backbone with T1 lines and
   the hub with OC3.  OSPF CE spoke router generates flow spec with
   rate-limit restrictions for spoke aggregated ip prefix.  The flow
   specification is then transmitted over the MPLS VPN core.  OSPF CE
   hub router uses the rule to limit the traffic towards the spoke.

   This document does not address optimizations in storage of flow-
   specification-LSAs in the intermediate routers or auto-discovery of
   flow specification capable routers.

2.  The Flow Specification Operation Description

2.1.  The Flow Specification Origins

   Flow specification rules can be either originated by the same router
   that originates the corresponding destination prefix.  For example,
   in case of an OSPFv2 network-LSA, the Designated Router will also
   advertise the corresponding flow specification rules that apply to
   the prefix advertised in the network-LSA.

   Each flow specification rule is encapsulated into a separate flow-
   specification-LSA that is described below in Section 3 and Section 4.

   The receiving routers first validate and then install flow
   specification rules into the flow routing table.

2.2.  Flow-specification-LSA scope and re-origination

   Because of the validation restrictions described in Section 11 the
   flow-specification-LSA MUST have the same scope as the scope of the
   corresponding LSA that caries the destination prefix information of
   the flow.  When the LSA describing the destination prefix is
   translated by the ABR router, this router SHOULD also re-originate
   the corresponding flow-specification-LSAs with the same scope as the
   LSA carrying the translated prefix.

2.3.  IPv4 and IPv6 rules




Shrivastava, et al.     Expires October 19, 2013                [Page 4]

Internet-Draft          OSPF Flow Specification               April 2013


   Currently the OSPFv2 specification [OSPFV2] supports only IPv4
   addresses and can therefore only carry IPv4 flow specification rules.
   OSPFv3 [OSPFV3-AF] supports both IPv4 and IPv6 address families but
   in separate instances.  Therefore a particular OSPFv3 instance can
   carry either IPv6 or IPv4 flow specification rules.

3.  OSPFv2 Flow-specification-LSA

   This extension makes use of the Opaque LSA [OPAQUE] to carry the flow
   specification rules.  This proposal uses type 10 for area scope and
   type 11 for AS scope.

3.1.  Link-State ID format

   The link-state ID of the Opaque LSA is divided into an Opaque Type
   field (the first 8 bits) and an Opaque ID (the remaining 24 bits).
   The Flow-specification-LSA uses type TBD.  The Opaque ID is an
   arbitrary value used to maintain multiple flow specification rules,
   which originate from a single router.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      TBD      |               Opaque ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Flow-specification-LSA LSA ID format

4.  OSPFv3 Flow-specification-LSA

   The OSPFv3 Flow specification information will be carried in the LSA
   with function code TBD.  The U bit will be set indicating that the
   OSPFv3 flow-specification-LSA should be flooded even if it is not
   understood.  For the area scope flow-specification-LSA S1 bit should
   be set and S2 should be 0.  For the AS scope, the S1 bit should be
   cleared and S2 bit should be set.  Like the OSPFv2 Opaque ID field,
   the Link State ID is an arbitrary value used to maintain multiple
   flow specification rules originating from a single router.

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |            LS age             |1|S12|             TDB         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                         Link State ID                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                       Advertising Router                      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Shrivastava, et al.     Expires October 19, 2013                [Page 5]

Internet-Draft          OSPF Flow Specification               April 2013


         |                       LS sequence number                      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |        LS checksum           |             Length             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-                            TLVs                             -+
         |                             ...                               |


                       OSPFv3 Flow-specification-LSA

5.  Flow-specification-LSA payload

   The LSA payload consists of one or more nested Type/Length/Value
   (TLV) triplets as described in Section 2.3.2 of [MPLS-TE].

   Each rule consists of one or more specification component types that
   identify the flow followed by optional flow specification filtering
   action types.

6.  IPv4 Flow Specification

   [BGP-FLOWSPEC] defines 12 flow specification component types:

     Type  Description
     ----  ------------------
       1   Destination Prefix
       2   Source Prefix
       3   IP Protocol
       4   Port
       5   Destination Port
       6   Source Port
       7   ICMP type
       8   ICMP code
       9   TCP flags
      10   Packet length
      11   DSCP
      12   Fragment



   Each of the flow specification component types is defined in a
   separate TLV.

   The flow specification component type is stored in the lower 8 bits
   of the 16-bit type field.





Shrivastava, et al.     Expires October 19, 2013                [Page 6]

Internet-Draft          OSPF Flow Specification               April 2013


   The format of each flow specification component type TLV is outlined
   below.

6.1.  Destination Prefix TLV

   Defines the destination prefix to match.

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         0     |         1     |              5                |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          IPv4 Prefix                          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Prefix Length |         Must Be Zero                          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



6.2.  Source Prefix TLV

   The encoding is similar to the destination prefix TLV.  The ype field
   is set to 2.

6.3.  IP Protocol

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |         3     |             Length            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Operator    |                     Value                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                              ...                              |




   The Value field has a variable length and the length is determined by
   the two bits len field in the operator byte.

6.4.  Port

   The same encoding as for component type IP Protocol.  The TLV Type
   field is set to 4.

6.5.  Destination port




Shrivastava, et al.     Expires October 19, 2013                [Page 7]

Internet-Draft          OSPF Flow Specification               April 2013


   The same encoding as for component type IP Protocol.  The TLV type
   field is set to 5.

6.6.  Source port

   The same encoding as for component type IP Protocol.  The TLV type
   field is set to 6.

6.7.  ICMP Type

   The same encoding as for component type IP Protocol.  The TLV Type
   field is set to 7.

6.8.  ICMP code

   The same encoding as for component type IP Protocol.  The TLV Type
   field is set to 8.

6.9.  TCP flags

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |         9     |             Length            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Operator    |                   Bitmask                     |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                              ...                              |




   The Bitmask field is of varying length and determined by the two bits
   len field in the operator byte.

6.10.  Packet length

   The same encoding as for component type IP Protocol.  The TLV Type
   field is set to 10.

6.11.  DSCP (Diffserv Code Point)

   The same encoding as for component type P Protocol.  The TLV Type
   field is set to 11.

6.12.  Fragment





Shrivastava, et al.     Expires October 19, 2013                [Page 8]

Internet-Draft          OSPF Flow Specification               April 2013


          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |               |        12     |             Length            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Operator    |     Bitmask   |              ...              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                              ...                              |




7.  IPv6 Flow Specification

   [draft-raszuk-idr-flow-spec-v6] defines the 12 flow specification
   component types for IPv6.

     Type  Description
     ----  ------------------
        1  Destination IPv6 Prefix
        2  Source IPv6 Prefix
        3  Next Header
        4  Port
        5  Destination port
        6  Source port
        7  ICMP type
        8  ICMP code
        9  TCP flags
       10  Packet length
       11  Traffic Class
       12  Reserved
       13  Flow Label


                              Component Types

   Each of the flow specification component types is defined in a
   separate TLV.

   The flow specification component type is stored in the lower 8 bits
   of the 16-bit type field.

   The format of IPv6 flow specification component type TLV that are
   different from the IPv4 outlined below.

7.1.  Destination IPv6 Prefix TLV

   Defines the destination prefix to match.



Shrivastava, et al.     Expires October 19, 2013                [Page 9]

Internet-Draft          OSPF Flow Specification               April 2013


          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         0     |         1     |          Length               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Prefix Length | Prefix Offset |                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
         |                                 IPv6 Prefix                   |
         +                                                               +



   The IPv6 Prefix field has variable length.  The length of the field
   is calculated from the TLV Length field.

7.2.  Source IPv6 Prefix TLV

   The encoding is similar to the component type Destination IPv6 Prefix
   TLV.  The Type field is set to 2.

7.3.  Traffic Class

   The same encoding as for component type IP Protocol.  The TLV Type
   field is set to 11.

7.4.  Flow Label

   The same encoding as for component type IP Protocol.  The TLV Type
   field is set to 13.

8.  IPv4 Traffic Filtering Actions

   In the [BGP-FLOWSPEC], the IPv4 filtering action types are
   standardized as BGP extended community attributes.  In the OSPF, the
   filtering actions are carried in the TLVs of the flow-specification-
   LSA.  The TLV type values are the same as the BGP extended community
   types for the filtering actions:

     Type  Description
     ----  ------------------
     8006  Traffic-rate
     8007  Traffic-action
     8009  Traffic-marking



   A filtering action TLV should precede the flow specification
   component TLV.  A filtering action TLV may or may not be present in a



Shrivastava, et al.     Expires October 19, 2013               [Page 10]

Internet-Draft          OSPF Flow Specification               April 2013


   flow-specification-LSA.  If not present, the default action is to
   accept the traffic that matches that particular rule.

   The most significant bit of the 16-byte type field is set to 1,
   distinguishing this TLV from the flow specification component TLV.

   Below are the formats of encodeding for different IPv4 action types.

8.1.  Traffic-rate

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       0x80    |         6     |             4                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          Traffic-rate                         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



8.2.  Traffic-action

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       0x80    |         7     |             1                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           |S|T|                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The traffic-action is encoded in the 2 least significant bits of the
   octet.

8.3.  Redirect

   The Redirect as defined in [BGP-FLOWSPEC] is not applicable to the
   OSPF.

8.4.  Traffic-marking

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       0x80    |         9     |             1                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   |DSCP Value |                                               |



Shrivastava, et al.     Expires October 19, 2013               [Page 11]

Internet-Draft          OSPF Flow Specification               April 2013


         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The DSCP value encoded in the 6 least significant bits of the octet.

9.  IPv6 Traffic Filtering Actions

   [draft-raszuk-idr-flow-spec-v6] defines 3 flow specification action
   types.  Those types are standardized as BGP extended community
   attributes.  In OSPF, the IPv6 filtering actions are defined in TLVs.
   The type values are the same as the BGP extended community types for
   the filtering actions.

     Type  Description
     ----  ------------------
     8006  Traffic-rate
     8007  Traffic-action
     8009  Traffic-marking



   The flow specification filtering action type uses the full 16 bits
   with the highest bit set to 1.

   The format of IPv6 filtering action types TLV that are different from
   the IPv4 outlined below.

9.1.  Traffic-marking

          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
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |       0x80    |         9     |             1                 |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | Traffic Class |                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



10.  Order of Traffic Filtering Rules

   With traffic filtering rules, more than one rule may match a
   particular traffic flow.  The order of applying the rules is the same
   as described in Section 5.1 of [BGP-FLOWSPEC].

11.  Validation Procedure




Shrivastava, et al.     Expires October 19, 2013               [Page 12]

Internet-Draft          OSPF Flow Specification               April 2013


   When a router receives the flow-specification-LSA from its
   neighboring router, it validates the information before accepting the
   filtering rule.  A flow specification rule is considered valid if and
   only if:

   a) The originator of the flow specification rule matches the
   originator of the best-match unicast route for the destination prefix
   embedded in the flow specification.

   The flow specification originator is identified by the Router ID of
   the flow-specification-LSA.

   To identify the originator of an OSPF route, look into the
   corresponded OSPF routing table entry:

   - for intra-area paths, the Link State Origin field of the path
   structure is compared

   - for inter-area and external paths, the Advertising router field of
   the path structure is compared.

   When multiple equal-cost paths exist in the routing table entry, each
   path could end up having a separate set of flow specification rules.

   b) The routing table does not have more specific unicast routes, when
   compared with the flow destination prefix, that have been received
   from a different router than the best-match unicast route, which has
   been determined in step a).

   Under certain scenarios the validation step can be bypassed.  This is
   outside of the scope of this document.

12.  Security Considerations

   As long as traffic filtering rules are restricted to match the
   corresponding unicast routing paths for the relevant prefixes, the
   security characteristics of this proposal are equivalent to the
   existing security properties of OSPF routing.

   Where it is not the case, this would open the door to further denial-
   of-service attacks.

13.  IANA Considerations

   The following IANA assignment was made from an existing registry:

   The OSPFv2 opaque LSA type TBD has been reserved for the OSPFv2 flow-
   specification-LSA.



Shrivastava, et al.     Expires October 19, 2013               [Page 13]

Internet-Draft          OSPF Flow Specification               April 2013


   The OSPFv3 LSA function code TDB has been reserved for the OSPFv3
   flow-specification-LSA.

   For the purpose of this work, IANA has created a new registry
   entitled: "OSPF IPv4 Flow Spec Component Types".  The following
   component types have been registered:

   Type 1 - Destination Prefix

   Type 2 - Source Prefix

   Type 3 - IP Protocol

   Type 4 - Port

   Type 5 - Destination port

   Type 6 - Source port

   Type 7 - ICMP type

   Type 8 - ICMP code

   Type 9 - TCP flags

   Type 10 - Packet length

   Type 11 - DSCP

   Type 12 - Fragment

   For the purpose of this work, IANA has created a new registry
   entitled: "OSPF IPv6 Flow Spec Component Types".  The following
   component types have been registered:

   Type 1 - Destination IPv6 Prefix

   Type 2 - Source IPv6 Prefix

   Type 3 - Next Header

   Type 4 - Port

   Type 5 - Destination port

   Type 6 - Source port

   Type 7 - ICMP type



Shrivastava, et al.     Expires October 19, 2013               [Page 14]

Internet-Draft          OSPF Flow Specification               April 2013


   Type 8 - ICMP code

   Type 9 - TCP flags

   Type 10 - Packet length

   Type 11 - Traffic Class

   Type 12 - Reserved

   Type 13 - Flow Label

   For the purpose of this work, IANA has created a new registry
   entitled: "OSPF IPv4 Flow Specification Action Types".  The following
   component types have been registered:

   Type 0x8006 - Flow spec traffic-rate

   Type 0x8007 - Flow spec traffic-action

   Type 0x8009 - Flow spec traffic-remarking

   For the purpose of this work, IANA has created a new registry
   entitled: "OSPF IPv6 Flow Specification Action Types".  The following
   component types have been registered:

   Type 0x8006 - Flow spec traffic-rate

   Type 0x8007 - Flow spec traffic-action

   Type 0x8009 - Flow spec traffic-remarking

14.  Acknowledgements

15.  Normative References

   [BGP-FLOWSPEC]
              Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
              and D. McPherson, "Dissemination of Flow Specification
              Rules", RFC 5575, August 2009.

   [MPLS-TE]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630, September
              2003.

   [OPAQUE]   Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
              OSPF Opaque LSA Option", RFC 5250, July 2008.




Shrivastava, et al.     Expires October 19, 2013               [Page 15]

Internet-Draft          OSPF Flow Specification               April 2013


   [OSPFV2]   Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [OSPFV3-AF]
              Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
              Aggarwal, "Support of Address Families in OSPFv3", RFC
              5838, April 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [draft-raszuk-idr-flow-spec-v6]
              Raszuk, R., "Dissemination of Flow Specification Rules for
              IPv6", March 2012.

Authors' Addresses

   Rashmi Shrivastava
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134
   US

   Email: rashi@cisco.com


   Mike Dubrovsky
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134
   US

   Email: mdubrovs@cisco.com


   Keyur Patel
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134
   US

   Email: keyupate@cisco.com










Shrivastava, et al.     Expires October 19, 2013               [Page 16]

Internet-Draft          OSPF Flow Specification               April 2013


   Burjiz Pithawala
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134
   US

   Email: bpithaw@cisco.com











































Shrivastava, et al.     Expires October 19, 2013               [Page 17]