[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
Idr Working Group                                               Q. Liang
Internet-Draft                                                    J. You
Intended status: Standards Track                                  Huawei
Expires: January 6, 2016                                    July 5, 2015


              Carrying Label Information for BGP FlowSpec
                 draft-liang-idr-bgp-flowspec-label-00

Abstract

   This document specifies a method in which the label mapping
   information for a particular FlowSpec rule is piggybacked in the same
   Border Gateway Protocol (BGP) Update message that is used to
   distribute the FlowSpec rule.  Based on the proposed method, the
   Label Switching Routers (LSRs) (except the ingress LSR) on the Label
   Switched Path (LSP) can use label to indentify the traffic matching a
   particular FlowSpec rule; this facilitates monitoring and traffic
   statistics for FlowSpec rules.  Meanwhile, using label for FlowSpec
   rule can improve forwarding performance in BGP VPN/MPLS networks.

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 [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 January 6, 2016.








Liang & You              Expires January 6, 2016                [Page 1]


Internet-Draft                BGP FlowSpec                     July 2015


Copyright Notice

   Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [RFC5575] defines the flow specification (FlowSpec) that is an
   n-tuple consisting of several matching criteria that can be applied
   to IP traffic.  The matching criteria can include elements such as
   source and destination address prefixes, IP protocol, and transport
   protocol port numbers.  A given IP packet is said to match the
   defined flow if it matches all the specified criteria.  [RFC5575]
   also defines filtering actions, such as rate limit, redirect,
   marking, associated with each flow specification.  A new Border
   Gateway Protocol Network Layer Reachability Information (BGP NLRI)
   (AFI/SAFI: 1/133 for IPv4, AFI/SAFI: 1/134 for VPNv4) encoding format
   is used to distribute traffic flow specifications.

   [RFC3107] specifies the way in which the label mapping information
   for a particular route is piggybacked in the same Border Gateway
   Protocol Update message that is used to distribute the route itself.
   Label mapping information is carried as part of the Network Layer
   Reachability Information (NLRI) in the Multiprotocol Extensions
   attributes.  The Network Layer Reachability Information is encoded as
   one or more triples of the form <length, label, prefix>.  The NLRI




Liang & You              Expires January 6, 2016                [Page 2]


Internet-Draft                BGP FlowSpec                     July 2015


   contains a label is indicated by using Subsequent Address Family
   Identifier (SAFI) value 4.

   [RFC4364] describes a method in which each route within a Virtual
   Private Network (VPN) is assigned a Multiprotocol Label Switching
   (MPLS) label.  If the Address Family Identifier (AFI) field is set to
   1, and the SAFI field is set to 128, the NLRI is an MPLS-labeled VPN-
   IPv4 address.

   In BGP VPN/MPLS networks, label switching is more efficient than IP
   routing.  As FlowSpec rules are used for packet processing and
   forwarding, label-based forwarding can effectively improve the route
   lookup performance in the data plane.  When FlowSpec rules on
   multiple forwarding devices in the network bound with labels form one
   or more LSPs, only the ingress LSR (Label Switching Router) needs to
   identify a particular traffic flow based on the matching criteria and
   then steers the packet to a corresponding LSP (Label Switched Path).
   Other LSRs of the LSP just need to forward the packet according to
   the label carried in it.

   Though the FlowSpec rule could use the label(s) bound with the best-
   match unicast route for the destination prefix embedded in the
   FlowSpec rule or the best-match route to the target IP in the
   'redirect to IP' action, this way means that if two or more FlowSpec
   rules have the same best-match unicast route for the embedded
   destination prefix or the same best-match route to target IP in the
   'redirect to IP' action; they would be mapped to the same label.
   This would affect monitoring and traffic statistics facilities,
   because each FlowSpec rule requires an independent statistic and log
   data, which is described in Section 9 [RFC5575].  The LSRs (except
   the ingress LSR) on the LSP can use label to indentify the traffic
   matching a particular FlowSpec rule; this facilitates monitoring and
   traffic statistics for FlowSpec rules.

   So this document proposes that the BGP router supports to allocate a
   unique label to a FlowSpec rule, the forwarding path is still decided
   by the best-match unicast route for the embedded destination prefix
   or the best-match route to target IP in the 'redirect to IP' action.
   Figure 1 gives an example that FlowSpec rule bound with a label is
   disseminated in the network.











Liang & You              Expires January 6, 2016                [Page 3]


Internet-Draft                BGP FlowSpec                     July 2015


                  Option-B inter-AS connection
                  |<------AS1----->|    |<------AS2----->|
                  +-----+    +-----+    +-----+    +-----+
       VPN 1,IP1..| PE1 |====|ASBR1|----|ASBR2|====| PE2 |..VPN1,IP2
                  +-----+    +-----+    +-----+    +-----+
                     | LDP LSP1 |          | LDP LSP2 |
                     | -------> |          | -------> |
                     |-------BGP VPN Flowspec LSP---->|
                 (Label1)    (Label2)   (Label3)   (Label4)
                    Figure 1: Usage of FlowSpec with Label

  FlowSpec rule1 (injected in PE2):
       Filters:
          destination ip prefix:IP2/32
          source ip prefix:IP1/32
       Actions:
          traffic-marking: 1

  Labels allocated for FlowSpec1:
       Label4 allocated by PE2
       Label3 allocated by ASBR2
       Label2 allocated by ASBR1
       Label1 allocated by PE1

  PE2 disseminates the FlowSpec1 bound with Label4 to ASBR2.
  ASBR2 disseminates the FlowSpec1 bound with Label3 to ASBR1.
  ASBR1 disseminates the FlowSpec1 bound with Label2 to PE1.

  Forwarding information for the traffic from IP1 to IP2 in the Routers:
       PE1: in(<IP2,IP1>) --> out(Label2)
       ASBR1: in(Label2) --> out(Label3)
       ASBR2: in(Label3) --> out(Label4)
       PE2: in(Label4) --> out(--)

   So ASBR1 can do traffic statistics for FlowSpec rule 1 based on
   Label2; ASBR2 can do it based on Label3; and PE2 can do it based on
   Label4.

2.  Terminology

   This section contains definitions of terms used in this document.

      Flow Specification (FlowSpec): A flow specification is an n-tuple
      consisting of several matching criteria that can be applied to IP
      traffic, including filters and actions.  Each FlowSpec consists of
      a set of filters and a set of actions.





Liang & You              Expires January 6, 2016                [Page 4]


Internet-Draft                BGP FlowSpec                     July 2015


3.  Protocol Extensions

   In this document, BGP is used to distribute the FlowSpec rule bound
   with label(s).  Two new SAFIs should be defined, i.e. SAFI: TBD1 for
   IP FlowSpec rule bound with label(s), SAFI: TBD2 for VPN FlowSpec
   rule bound with label(s).  The Network Layer Reachability Information
   for this FlowSpec rule is encoded as one or more triples of the form
   <length, RD (optional), FlowSpec, label(s) (optional)>, whose fields
   are described below:

                       +---------------------------+
                       |   Length (1 or 2 octets)  |
                       +---------------------------+
                       |   RD (8 octets, optional) |
                       +---------------------------+
                       |   Flow Filters (variable) |
                       +---------------------------+
                       |   Separator               |
                       +---------------------------+
                       |   Label(s)                |
                       +---------------------------+

   The use and the meaning of these fields are as follows:

      Length: The Length field indicates the length in bytes of the flow
      filters, the RD, the separator and the label(s).

      RD: Route Distinguisher (8 bytes), when SAFI=TBD2.

      Separator: This field is the constant bit pattern 0xfe (hex),which
      indicates the separation between the flow filters field and
      lable(s) field.  This value should not be used by flow filters.

      Label(s): This field carries zero or more labels (that corresponds
      to the stack of labels [RFC3032]).  Each label is encoded as 3
      octets, where the high-order 20 bits contain the label value, and
      the low order bit contains "Bottom of Stack" [RFC3032].

      Flow Filters: This field consists of several optional
      subcomponents defined in section 4 [RFC5575].  The combination of
      RD and Flow Filters is equal to the flow-spec NLRI defined in
      [RFC5575].

   For the purpose of BGP route key processing, only the Route
   Distinguisher, Flow Filters fields are considered to be part of the
   prefix in the NLRI.





Liang & You              Expires January 6, 2016                [Page 5]


Internet-Draft                BGP FlowSpec                     July 2015


4.  IANA Considerations

   For the purpose of this work, IANA should allocate values for two
   SAFIs:

      SAFI TBD1 for IP FlowSpec rule bound with label(s).

      SAFI TBD2 for VPN FlowSpec rule bound with label(s).

5.  Security considerations

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP.

6.  Acknowledgement

   The authors would like to thank Shunwan Zhuang, Zhenbin Li and Peng
   Zhou for their comments.

7.  Normative References

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

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

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

Authors' Addresses

   Qiandeng Liang
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing,  210012
   China

   Email: liangqiandeng@huawei.com




Liang & You              Expires January 6, 2016                [Page 6]


Internet-Draft                BGP FlowSpec                     July 2015


   Jianjie You
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing,  210012
   China

   Email: youjianjie@huawei.com












































Liang & You              Expires January 6, 2016                [Page 7]