Internet DRAFT - draft-gao-fsp-motivations

draft-gao-fsp-motivations



 



INTERNET-DRAFT                                                    J. Gao
Intended Status: Informational                                Individual
Expires: April 17, 2020                                 October 15, 2019


    Motivations and Design Choices of the Flexible Session Protocol
                      draft-gao-fsp-motivations-02

Abstract

   This document introduces the motivation to design the Flexible
   Session Protocol which supports mobility and multihoming at the
   transport layer. FSP is to avoid the routing scalability problem in
   the IPv6 internetwork.

   The document serves to explain choices of design goals of FSP as
   well.

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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

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


Gao                      Expires April 17, 2020                 [Page 1]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2. Mobility and Multihoming Support in the IPv6 Internet . . .  4
   2. Survey of Infrastructure-Dependent Mobility Support . . . . . .  4
     2.1. Separation of Identifier and Locator  . . . . . . . . . . .  5
       2.1.1. Host Identity Protocol  . . . . . . . . . . . . . . . .  5
       2.1.2. Identifier-Locator Network Protocol . . . . . . . . . .  6
       2.2.3. The Locator/ID Separation Protocol  . . . . . . . . . .  7
     2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.2.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . .  8
       2.2.2. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . . 10
       2.2.3. Hierarchical Mobile IPv6  . . . . . . . . . . . . . . . 10
       2.2.4. Network Mobility (NEMO) Basic Support Protocol  . . . . 11
     2.3. MinimalT  . . . . . . . . . . . . . . . . . . . . . . . . . 12
     2.4. DMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   3. Survey of Infrastructure-Independent Mobility Support . . . . . 14
     3.1. IKEv2 Mobility and Multihoming Protocol . . . . . . . . . . 14
     3.2. Mobile SCTP . . . . . . . . . . . . . . . . . . . . . . . . 17
     3.3. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . . 18
     3.4. REST Architecture Style . . . . . . . . . . . . . . . . . . 18
   4. A Solution at the Origin of the Problem . . . . . . . . . . . . 20
     4.1. Separation of Identity and Locator at Transport Layer . . . 20
     4.2. Adding Programmer-Friendly Session Semantics  . . . . . . . 20
       4.2.1. Intuitiveness . . . . . . . . . . . . . . . . . . . . . 20
       4.2.2. Really Parallel Streams . . . . . . . . . . . . . . . . 21
       4.2.3. Mixed Traffic Class . . . . . . . . . . . . . . . . . . 21
       4.2.4. Session Adjournment and Resumption  . . . . . . . . . . 21
     4.3. Adding Programmer-friendly Security Service . . . . . . . . 21
       4.3.1. Ubiquitous Encryption and Authentication of Data  . . . 21
       4.3.2. Key Establishment versus Application of Keys  . . . . . 22
   5. Choices of Design Goals . . . . . . . . . . . . . . . . . . . . 22
     5.1. Featured Scenarios  . . . . . . . . . . . . . . . . . . . . 22
       5.1.1. Goal: Support for Mobile Computing  . . . . . . . . . . 22
       5.1.2. Goal: Adaptable to Specific-Purpose Networks  . . . . . 23
       5.1.3. Goal: Adaptable to Constrained-Node Networks  . . . . . 23
       5.1.4. Non-Goal: General Multicast Transport . . . . . . . . . 24
     5.2. Optimizing towards IPv6 . . . . . . . . . . . . . . . . . . 24
 


Gao                      Expires April 17, 2020                 [Page 2]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


       5.2.1. Goal: Promoting Transition towards IPv6 . . . . . . . . 24
       5.2.2. Goal: NAT friendliness in IPv4 network  . . . . . . . . 24
       5.2.3. Non-Goal: NAT friendliness in IPv6 network  . . . . . . 24
     5.3. Congestion Control  . . . . . . . . . . . . . . . . . . . . 24
       5.3.1. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 24
       5.3.2. Goal: Host-Aggregated Congestion Control  . . . . . . . 24
       5.3.3. Goal: Congestion Control Per Traffic Class  . . . . . . 25
       5.3.4. Debatable: TCP Friendliness . . . . . . . . . . . . . . 25
     5.4. Infrastructure Independency . . . . . . . . . . . . . . . . 25
       5.4.1. Goal: More Efficient Use of the IPv6 Address Space  . . 25
       5.4.2. Goal: ECN Awareness . . . . . . . . . . . . . . . . . . 25
       5.4.3. Non-Goal: Inventing New Rendezvous Mechanism  . . . . . 25
     5.5. Feasibility of Hardware Acceleration  . . . . . . . . . . . 26
       5.5.1. Goal: Hardware-Accelerated Cryptography . . . . . . . . 26
       5.5.2. Goal: Hardware-assisted Header Processing . . . . . . . 26
     5.6. QoS and Multipath Issues  . . . . . . . . . . . . . . . . . 26
       5.6.1. Goal: Minimal Delay Service for Milk Like Payload . . . 26
       5.6.2. To be studied: Resource Reservation . . . . . . . . . . 26
       5.6.3. To be studied: PMTU Discovery . . . . . . . . . . . . . 27
     5.7. On-the-wire Compression . . . . . . . . . . . . . . . . . . 27
       5.7.1. Goal: Compatibility with Pre-compression  . . . . . . . 27
       5.7.2. Goal: Decompression Speed . . . . . . . . . . . . . . . 27
       5.7.3. Goal: System Robustness . . . . . . . . . . . . . . . . 27
       5.7.4. Non-Goal: Versatility of On-the-Wire Compression  . . . 28
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 28
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     8.1. Normative References  . . . . . . . . . . . . . . . . . . . 28
     8.2. Informative References  . . . . . . . . . . . . . . . . . . 31
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37


















 


Gao                      Expires April 17, 2020                 [Page 3]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


1. Introduction

   The motivation of designing the Flexible Session Protocol, which sits
   at the transport layer along with TCP [RFC0793], is to provide
   mobility and multihoming support, thus to make routing scalability
   problem [RFC4984] in the IPv6 [RFC8200] internetwork thoroughly
   avoidable.

   FSP means to be programmer-friendly by adding session semantics in
   the transport layer and providing security services that is flexible
   to adapt to new cryptography key establishment algorithm implemented
   at the application layer.

   FSP is originally intent to be an alternative of TLS [RFC8446],
   bundled with TCP, in application scenarios that favor high-
   performance and strong-security in IPv6 networks with mobility
   support.

   FSP can be easily tuned to work well for constrained-node networks
   [RFC7228].

   The document serves to explain some design choices of FSP as well.

1.1. Terminology

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

1.2. Mobility and Multihoming Support in the IPv6 Internet

   Various solutions exist in the IPv6 Internet that support mobility
   and/or multihoming. In this documents we survey infrastructure-
   dependent solutions such as HIP [RFC4423], ILNP [RFC6740], LISP
   [RFC6830], NEMO [RFC3963], MinimalT [MinimaLT], MIPv6 [RFC6275],
   PMIPv6 [RFC5213], HMIPv6 [RFC5380] and DMM [RFC7333], and
   infrastructure-independent solutions such as MOBIKE [RFC4555], Mobile
   SCTP, MPTCP [RFC7430] and REpresentation State Transfer architecture
   style [RESTful].

   This document draws heavily from earlier RFCs and other references
   when discusses these known solutions.

2. Survey of Infrastructure-Dependent Mobility Support

   Various solutions exist in the IPv6 Internet that support mobility
   and/or multihoming. Infrastructure-dependent proposals that support
   mobility often require some change of current Internet architecture.
 


Gao                      Expires April 17, 2020                 [Page 4]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   In this documents we surveys infrastructure-dependent solutions such
   as HIP, ILNP, LISP, NEMO, MinimalT, MIPv6, PMIPv6 and HMIPv6.

2.1. Separation of Identifier and Locator

2.1.1. Host Identity Protocol

   HIP architecture proposes Host Identity namespace that fills an
   important gap between the IP and DNS namespaces.  The Host Identity
   namespace consists of Host Identifiers (HIs).  A Host Identifier is
   cryptographic in its nature; it is the public key of an asymmetric
   key-pair. Each host will have at least one Host Identity, but it will
   typically have more than one.  Each Host Identity uniquely identifies
   a single host; i.e., no two hosts have the same Host Identity.  The
   Host Identity, and the corresponding Host Identifier, can be either
   public (e.g., published in the DNS) or unpublished.  Client systems
   will tend to have both public and unpublished Identities.

      Service ------ Socket                  Service ------ Socket
                       |                                      |
                       |                                      |
                       |                                      |
                       |                                      |
      End-point        |                    End-point --- Host Identity
               \       |                                      |
                \      |                                      |
                 \     |                                      |
                  \    |                                      |
      Location --- IP address                Location --- IP address


              Figure 1 New Stack Architecture Presented by HIP

   HIP decouples the transport from the internetworking layer, and binds
   the transport associations to the Host Identities.  Consequently, HIP
   can provide for a degree of internetworking mobility and multihoming
   at a low infrastructure cost.  HIP mobility [RFC8046] includes IP
   address changes (via any method) to either party. HIP links IP
   addresses together, when multiple IP addresses correspond to the same
   Host Identity, and if one address becomes unusable, or a more
   preferred address becomes available, existing transport associations
   can easily be moved to another address.

   When a node moves while communication is already ongoing, address
   changes are rather straightforward.  The peer of the mobile node can
   just accept a HIP or an integrity protected IPsec packet from any
   address and ignore the source address.

 


Gao                      Expires April 17, 2020                 [Page 5]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   In order to start the HIP exchange, the initiator node has to know
   how to reach the mobile node.  Although infrequently moving HIP nodes
   could use Dynamic DNS [RFC2136] to update their reachability
   information in the DNS, an alternative to using DNS in this fashion
   is to use a piece of new static infrastructure to facilitate
   rendezvous between HIP nodes.

   The mobile node keeps the rendezvous infrastructure continuously
   updated with its current IP address(es). The mobile nodes must trust
   the rendezvous mechanism to properly maintain their HIT and IP
   address mappings. The rendezvous mechanism [RFC8004] is also needed
   if both of the nodes happen to change their address at the same time,
   either because they are mobile and happen to move at the same time,
   because one of them is off-line for a while, or because of some other
   reason.

2.1.2. Identifier-Locator Network Protocol

   The key idea proposed for ILNP is to directly and specifically change
   the overloaded semantics of the IP Address.  The Internet community
   has indicated explicitly, several times, that this use of overloaded
   semantics is a significant problem with the use of the Internet
   protocol today [RFC1498] [RFC2101] [RFC2956] [RFC4984]. 

   ILNP explicitly replaces the use of IP Addresses with two distinct
   name spaces, each having distinct and different semantics:

   a) Identifier: a non-topological name for uniquely identifying a
      node.

   b) Locator: a topologically bound name for an IP subnetwork.

   The use of these two new namespaces in comparison to IP is given in
   Table 1. The table shows where existing names are used for state
   information in end-systems or protocols.

              Layer     |          IP          |     ILNP
         ---------------+----------------------+---------------
           Application  |  FQDN or IP Address  |  FQDN
           Transport    |  IP Address          |  Identifier
           Network      |  IP Address          |  Locator
           Physical i/f |  IP Address          |  MAC address
         ---------------+----------------------+---------------

           FQDN = Fully Qualified Domain Name
           i/f = interface
           MAC = Media Access Control

 


Gao                      Expires April 17, 2020                 [Page 6]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


         Table 1: Use of Names for State Information in Various
                 Communication Layers for IP and ILNP

   ILNP supports mobility directly. Essentially, for ILNP, mobility is
   implemented by enabling:

   a) Locator values to be changed dynamically by a node, including for
      active network-layer sessions.

   b) use of Locator Updates [RFC6743] to allow active network-layer
      sessions to be maintained.

   c) for those hosts that expect incoming network-layer or transport-
      layer session requests (e.g., servers), updates to the relevant
      DNS entries for those hosts [RFC6742].

2.2.3. The Locator/ID Separation Protocol

   The Locator/Identifier Separation Protocol provides a set of
   functions for routers to exchange information used to map from
   Endpoint Identifiers (EIDs) that are not globally routable to
   routable Routing Locators (RLOCs).  It also defines a mechanism for
   these LISP routers to encapsulate IP packets addressed with EIDs for
   transmission across a network infrastructure that uses RLOCs for
   routing and forwarding.

   The approach that LISP takes to solving the routing scalability
   problem is to replace IP addresses with two new types of numbers:
   Routing Locators (RLOCs), which are topologically assigned to network
   attachment points (and are therefore amenable to aggregation) and
   used for routing and forwarding of packets through the network; and
   Endpoint Identifiers (EIDs), which are assigned independently from
   the network topology, are used for numbering devices, and are
   aggregated along administrative boundaries.  LISP then defines
   functions for mapping between the two numbering spaces and for
   encapsulating traffic originated by devices using non-routable EIDs
   for transport across a network infrastructure that routes and
   forwards using RLOCs.  Both RLOCs and EIDs are syntactically
   identical to IP addresses; it is the semantics of how they are used
   that differs.

   LISP implementations must provide ITRs and ETRs.

   An ITR is a router that resides in a LISP site.  Packets sent by
   sources inside of the LISP site to destinations outside of the site
   are candidates for encapsulation by the ITR. The ITR treats the IP
   destination address as an EID and performs an EID-to-RLOC mapping
   lookup. The router then prepends an "outer" IP header with one of its
 


Gao                      Expires April 17, 2020                 [Page 7]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   globally routable RLOCs in the source address field and the result of
   the mapping lookup in the destination address field.

   An ETR is a router that accepts an IP packet where the destination
   address in the "outer" IP header is one of its own RLOCs. The router
   strips the "outer" header and forwards the packet based on the next
   IP header found. In general, an ETR receives LISP-encapsulated IP
   packets from the Internet on one side and sends decapsulated IP
   packets to site end-systems on the other side. ETR functionality does
   not have to be limited to a router device.  A server host can be the
   endpoint of a LISP tunnel as well.

   A mobile device can use the LISP infrastructure to achieve mobility
   by implementing the LISP encapsulation and decapsulation functions
   and acting as a simple ITR/ETR.  By doing this, such a "LISP mobile
   node" can use topologically independent EID IP addresses that are not
   advertised into and do not impose a cost on the global routing
   system. These EIDs are maintained at the edges of the mapping system
   (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
   only the correspondents of the LISP mobile node.

   It requires a index system that stores the mappings between EIDs and
   RLOCs. The index system may be and usually is large-scale
   distributed, such as Locator/ID Separation Protocol Alternative
   Logical Topology [RFC6836], and constitutes the new infrastructure
   that supports LISP.

2.2. Tunneling

2.2.1. Mobile IPv6

   Mobility Support in IPv6, known as Mobile IPv6 or MIPv6, is a
   protocol that allows nodes to remain reachable while moving around in
   the IPv6 Internet. It allows a mobile node to move from one link to
   another without changing the mobile node's "home address".  Packets
   may be routed to the mobile node using this address regardless of the
   mobile node's current point of attachment to the Internet.  The
   mobile node may also continue to communicate with other nodes
   (stationary or mobile) after moving to a new link.  The movement of a
   mobile node away from its home link is thus transparent to transport
   and higher-layer protocols and applications.

   In IPv4 mobility [RFC5944], when an endpoint is away from home,
   packets to it are encapsulated and forwarded via a home agent that
   resides in the home area the endpoint's address belongs to. The home
   agent will encapsulate and forward packets either directly to the
   endpoint or to a foreign agent that resides where the endpoint has
   moved to. Packets from the endpoint may be sent directly to the
 


Gao                      Expires April 17, 2020                 [Page 8]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   correspondent node, may be sent via the foreign agent, or may be
   reverse-tunneled back to the home agent for delivery to the mobile
   node.

   Mobile IPv6 allows nodes to move within the Internet topology while
   maintaining reachability and ongoing connections between mobile and
   correspondent nodes as well.  To do this, a mobile node sends binding
   updates (BUs) to its home agent (HA) every time it moves.

   The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both
   from the experiences gained from the development of Mobile IP support
   in IPv4 (Mobile IPv4), and from the opportunities provided by IPv6. 
   Mobile IPv6 thus shares many features with Mobile IPv4, but is
   integrated into IPv6 and offers many other improvements. The major
   differences between Mobile IPv4 and Mobile IPv6 is summarized as:

   o  There is no need to deploy special routers as "foreign agents", as
      in Mobile IPv4. Mobile IPv6 operates in any location without any
      special support required from the local router.

   o  Support for route optimization is a fundamental part of the
      protocol, rather than a nonstandard set of extensions.

   o  Mobile IPv6 route optimization can operate securely even without
      pre-arranged security associations.  It is expected that route
      optimization can be deployed on a global scale between all mobile
      nodes and correspondent nodes.

   o  Support is also integrated into Mobile IPv6 for allowing route
      optimization to coexist efficiently with routers that perform
      "ingress filtering".

   o  The IPv6 Neighbor Unreachability Detection ensures symmetric
      reachability between the mobile node and its default router in the
      current location.

   o  Most packets sent to a mobile node while away from home in Mobile
      IPv6 are sent using an IPv6 routing header rather than IP
      encapsulation, reducing the amount of resulting overhead compared
      to Mobile IPv4.

   o  Mobile IPv6 is decoupled from any particular link layer, as it
      uses IPv6 Neighbor Discovery [RFC4861] instead of the Address
      Resolution Protocol (ARP).  This also improves the robustness of
      the protocol.

   o  The use of IPv6 encapsulation (and the routing header) removes the
      need in Mobile IPv6 to manage "tunnel soft state".
 


Gao                      Expires April 17, 2020                 [Page 9]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   o  The dynamic home agent address discovery mechanism in Mobile IPv6
      returns a single reply to the mobile node.  The directed broadcast
      approach used in IPv4 returns separate replies from each home
      agent.

2.2.2. Proxy Mobile IPv6

   It is possible to support mobility for IPv6 nodes without host
   involvement by extending Mobile IPv6 signaling messages between a
   network node and a home agent.  This approach to supporting mobility
   does not require the mobile node to be involved in the exchange of
   signaling messages between itself and the home agent.  A proxy
   mobility agent in the network performs the signaling with the home
   agent and does the mobility management on behalf of the mobile node
   attached to the network.  Because of the use and extension of Mobile
   IPv6 signaling and home agent functionality, this protocol is
   referred to as Proxy Mobile IPv6 (PMIPv6).

   The Mobile Access Gateway (MAG) is such a proxy function on an access
   router. MAG manages the mobility-related signaling for a mobile node
   that is attached to its access link.  It is responsible for tracking
   the mobile node's movements to and from the access link and for
   signaling the mobile node's local mobility anchor.

   IP mobility for nodes that have mobile IP client functionality in the
   IPv6 stack as well as those nodes that do not, would be supported by
   enabling Proxy Mobile IPv6 protocol functionality in the network. 
   The advantages of developing a network-based mobility protocol based
   on Mobile IPv6 are:

   o  Reuse of home agent functionality and the messages/format used in
      mobility signaling.  Mobile IPv6 is a mature protocol with several
      implementations that have undergone interoperability testing.

   o  A common home agent would serve as the mobility agent for all
      types of IPv6 nodes.

2.2.3. Hierarchical Mobile IPv6

   Hierarchical Mobile IPv6 (HMIPv6) mobility management specification
   [RFC5380] introduces the concept of a hierarchical Mobile IPv6
   network, utilising a new node called the Mobility Anchor Point (MAP).

   MAP can be located at any level in a hierarchical network of routers,
   including the Access Router (AR).  The MAP will limit the amount of
   Mobile IPv6 signaling outside the local domain.

   The introduction of the MAP provides a solution that has these
 


Gao                      Expires April 17, 2020                [Page 10]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   benefits:

   o  The mobile node sends binding updates to the local MAP rather than
      the home agent (HA) (which is typically further away) and
      correspondent nodes (CNs). It mitigates delays caused by MIPv6
      signaling.

   o  Only one binding update message needs to be transmitted by the
      mobile node (MN) before traffic from the HA and all CNs is re-
      routed to its new location.  This is independent of the number of
      CNs with which the MN is communicating. It mitigates the tunneling
      burden on the home agent and alleviates the scalability problem.

   A MAP is essentially a local home agent.  The aim of introducing the
   hierarchical mobility management model in Mobile IPv6 is to enhance
   the performance of Mobile IPv6 while minimising the impact on Mobile
   IPv6 or other IPv6 protocols.

   It is pertinent to note that the use of the MAP does not rely on, or
   assume the presence of, a permanent home agent.  In other words, a
   mobile node need not have a permanent home address or home agent in
   order to be HMIPv6-aware or use the features of HMIPv6. A MAP may be
   used by a mobile node in a nomadic manner to achieve mobility
   management within a local domain.

2.2.4. Network Mobility (NEMO) Basic Support Protocol

   Network Mobility (NEMO) Basic Support Protocol is protocol extensions
   to Mobile IPv6 (MIPv6) to enable support for network mobility.  The
   extensions are backward compatible with Mobile IPv6.  In particular,
   a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent.

   The NEMO Basic Support ensures session continuity for all the nodes
   in the Mobile Network, even as the Mobile Router changes its point of
   attachment to the Internet.  It also provides connectivity and
   reachability for all nodes in the Mobile Network as it moves.  The
   solution supports both mobile nodes and hosts that do not support
   mobility in the Mobile Network.

   The solution proposes a bi-directional tunnel between the Mobile
   Router and its Home Agent.  This tunnel is set up when the Mobile
   Router sends a successful Binding Update to its Home Agent, informing
   the Home Agent of its current point of attachment. All traffic
   between the nodes in the Mobile Network and Correspondent Nodes
   passes through the Home Agent.  

   The solution described here does not place any restriction on the
   number of levels for nested mobility.  But note that nested mobility
 


Gao                      Expires April 17, 2020                [Page 11]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   might introduce significant overhead on the data packets as each
   level of nesting introduces another IPv6 header encapsulation.

   Multihoming for Mobile Routers was not discussed in NEMO Basic
   Support.

2.3. MinimalT

   Minimal Latency Tunneling [MinimaLT] is a network protocol that
   provides ubiquitous encryption for maximal confidentiality, including
   protecting packet headers. MinimaLT provides server and user
   authentication, extensive Denial-of-Service protections, and IP
   mobility while approaching perfect forward secrecy.

   A MinimaLT tunnel is a point-to-point entity that encapsulates the
   set of connections between two hosts. MinimaLT creates a tunnel on
   demand in response to the first packet received from a host or a
   local application's outgoing connection request. Tunnels provide
   server authentication, encryption, congestion control, and
   reliability.

   A MinimaLT tunnel contains a set of connections, that is, a single
   tunnel between two hosts encapsulates an arbitrary number of
   connections. Each connection is user-authenticated and provides two-
   way communication between a client application and service.

   MinimaLT identifies tunnels by their TID, the TID is pseudorandomly
   generated by the initiator. A tunnel's IP and UDP port can change
   without affecting communication. After changing its IP address or UDP
   port, a host simply assumes the next TID as with a rekey. The other
   host will recognize the new TID and will transition the tunnel to the
   new key, IP address, and UDP port.

   Central to the protocol is the MinimaLT directory service. The
   directory service resolves queries for (server) hostname information.
   It provides the server's directory certificate, signed by the
   server's long-term key. This returned certificate contains the
   server's IP address, UDP port, long-term key, zero padding (the
   minimum payload size of the initial packet), and a server ephemeral
   key.

   As MinimalT requires new directory service provided by the network
   infrastructure it is classified as infrastructure-dependent.

2.4. DMM

   Requirements for DMM reveals that the background behind the interest
   in studying DMM is primarily as follows.
 


Gao                      Expires April 17, 2020                [Page 12]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   (1)  More than ever, mobile users are consuming Internet content,
        including that of local Content Delivery Networks (CDNs).  Such
        traffic imposes new requirements on mobile core networks for
        data traffic delivery.

        Both traffic offloading and CDN mechanisms could benefit from
        the development of mobile architectures with fewer hierarchical
        levels introduced into the data path by the mobility management
        system.  This trend of "flattening" the mobile networks works
        best for direct communications among peers in the same
        geographical area.  Distributed mobility management in the
        flattening mobile networks would anchor the traffic closer to
        the point of attachment of the user.

   (2)  Today's mobile networks present service providers with new
        challenges.  Mobility patterns indicate that mobile nodes often
        remain attached to the same point of attachment for considerable
        periods of time [LOCATING-USER].  Specific IP mobility
        management support is not required for applications that launch
        and complete their sessions while the mobile node is connected
        to the same point of attachment.  However, IP mobility support
        is currently designed for always-on operation, maintaining all
        parameters of the context for each mobile subscriber for as long
        as they are connected to the network.  This can result in a
        waste of resources and unnecessary costs for the service
        provider.  Infrequent node mobility coupled with application
        intelligence suggest that mobility support could be provided
        selectively, thus reducing the amount of context maintained in
        the network.


   In centralized mobility management such as MIPv6, PMIPv6 or HMIPv6,
   the location information in terms of a mapping between the session
   identifier and the forwarding address is kept at a single mobility
   anchor, and packets destined to the session identifier are forwarded
   via this anchor.  In other words, such mobility management systems
   are centralized in both the control plane and the data plane (mobile
   node IP traffic).

   The main mobility management functions of MIPv6, PMIPv6, and HMIPv6
   are the following:

   1.  Anchoring Function (AF): allocation to a mobile node of an IP
       address, i.e., Home Address (HoA), or prefix, i.e., Home Network
       Prefix (HNP), topologically anchored by the advertising node. 
       That is, the anchor node is able to advertise a connected route
       into the routing infrastructure for the allocated IP prefixes. 
       This function is a control-plane function.
 


Gao                      Expires April 17, 2020                [Page 13]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   2.  Internetwork Location Management (LM) function: managing and
       keeping track of the internetwork location of an MN. It is a
       control-plane function.

       The location information may be a binding of the advertised IP
       address/prefix, e.g., HoA or HNP, to the IP routing address of
       the MN, or it may be a binding of a node that can forward packets
       destined to the MN.

       In a client-server protocol model, location query and update
       messages may be exchanged between a Location Management client
       (LMc) and a Location Management server (LMs).

   3.  Forwarding Management (FM) function: packet interception and
       forwarding to/from the IP address/prefix assigned to the MN,
       based on the internetwork location information, either to the
       destination or to some other network element that knows how to
       forward the packets to their destination.

       FM may optionally be split into the control plane (FM-CP) and
       data plane (FM-DP).

   In Mobile IPv6, the home agent (HA) typically provides the AF; the
   LMs is at the HA, whereas the LMc is at the MN; the FM function is
   distributed between the ends of the tunnel at the HA and the MN.

   In Proxy Mobile IPv6, the local mobility anchor (LMA) provides the 
   AF; the LMs is at the LMA, whereas the LMc is at the MAG; the FM
   function is distributed between the ends of the tunnel at the LMA and
   the MAG.

   In HMIPv6, the Mobility Anchor Point (MAP) serves as a location
   information aggregator between the LMs at the HA and the LMc at the
   MN.  The MAP also provides the FM function to enable tunneling
   between HA and itself, as well as tunneling between the MN and
   itself.

   Requirements for Distributed Mobility Management [RFC7333] states
   that distributed mobility management (DMM) is an alternative to the
   centralized deployment of the location information.

   While DMM does add scalability to mobile management tremendously it
   requires substantial infrastructure enhancement to be effective. 

3. Survey of Infrastructure-Independent Mobility Support

3.1. IKEv2 Mobility and Multihoming Protocol

 


Gao                      Expires April 17, 2020                [Page 14]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   IKEv2 [RFC7296] is used for performing mutual authentication, as well
   as establishing and maintaining IPsec Security Associations (SAs). 
   In the base IKEv2 protocol, the IKE SAs and tunnel mode IPsec SAs are
   created implicitly between the IP addresses that are used when the
   IKE_SA is established.  These IP addresses are then used as the outer
   (tunnel header) addresses for tunnel mode IPsec packets.

   There are scenarios where these IP addresses might change. One
   example is mobility: a host changes its point of network attachment
   and receives a new IP address.  Another example is a multihoming host
   that would like to change to a different interface if, for instance,
   the currently used interface stops working for some reason.

   The MOBIKE protocol provides a mechanism for updating the IP
   addresses of existing IKE and IPsec SAs is needed. 

   MOBIKE allows both parties to have several addresses, and there are
   up to N*M pairs of IP addresses that could potentially be used. The
   party that initiated the IKE_SA is responsible for deciding which
   address pair is used for the IPsec SAs and for collecting the
   information it needs to make this decision (such as determining which
   address pairs work or do not work).  The other party simply tells the
   initiator what addresses it has, but does not update the IPsec SAs
   until it receives a message from the initiator to do so.  This
   approach applies to the addresses in the IPsec SAs; in the IKE_SA
   case, the exchange initiator can decide which addresses are used.

   In MOBIKE, the initiator decides what addresses are used in the IPsec
   SAs.  That is, the responder does not normally update any IPsec SAs
   without receiving an explicit UPDATE_SA_ADDRESSES request from the
   initiator. The responder can, however, update the IKE_SA in some
   circumstances.

   Assumes that the initiator has already decided what the new addresses
   should be.  When this decision has been made, the initiator:

   o  Updates the IKE_SA with the new addresses, and sets the
      "pending_update" flag in the IKE_SA.

   o  Updates the IPsec SAs associated with this IKE_SA with the new
      addresses (unless the initiator's policy requires a return
      routability check before updating the IPsec SAs, and the check has
      not been done for this responder address yet).

   o  If the IPsec SAs were updated in the previous step: If NAT
      Traversal is not enabled, and the responder supports NAT
      Traversal, and the initiator either suspects or knows that a NAT
      is likely to be present, enables NAT Traversal.
 


Gao                      Expires April 17, 2020                [Page 15]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   o  If there are outstanding IKEv2 requests (requests for which the
      initiator has not yet received a reply), continues retransmitting
      them using the addresses in the IKE_SA (the new addresses).

   o  When the window size allows, sends an INFORMATIONAL request
      containing the UPDATE_SA_ADDRESSES notification (which does not
      contain any data), and clears the "pending_update" flag.

   o  If a new address change occurs while waiting for the response,
      starts again from the first step (and ignores responses to this
      UPDATE_SA_ADDRESSES request).

   When processing an INFORMATIONAL request containing the
   UPDATE_SA_ADDRESSES notification, the responder:

   o  Determines whether it has already received a newer 
      UPDATE_SA_ADDRESSES request than this one.  If it has, a normal
      response message is sent, but no other action is taken.

   o  Checks that the (source IP address, destination IP address) pair
      in the IP header is acceptable according to local policy.  If it
      is not, replies with a message containing the 
      UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).

   o  Updates the IP addresses in the IKE_SA with the values from the IP
      header.

   o  Replies with an INFORMATIONAL response.

   o  If necessary, initiates a return routability check for the new
      initiator address and waits until the check is completed.

   o  Updates the IPsec SAs associated with this IKE_SA with the new
      addresses.

   o  If NAT Traversal is supported and NAT detection payloads were
      included, enables or disables NAT Traversal.

   When the initiator receives the reply:

   o  If an address change has occurred after the request was firs 
      sent, no MOBIKE processing is done for the reply message because a
      new UPDATE_SA_ADDRESSES is going to be sent (or has already been
      sent, if window size greater than one is in use).

   o  If the response contains an UNACCEPTABLE_ADDRESSES notification,
      the initiator MAY select another addresses and retry the exchange,
      keep on using the previously used addresses, or disconnect.
 


Gao                      Expires April 17, 2020                [Page 16]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   o  It updates the IPsec SAs associated with this IKE_SA with the new
      addresses (unless this was already done earlier before sending the
      request; this is the case when no return routability check was
      required).

   o  If NAT Traversal is supported and NAT detection payloads were
      included, the initiator enables or disables NAT Traversal.

3.2. Mobile SCTP

   A local host may have multiple points of attachment to the Internet,
   giving it a degree of fault tolerance from hardware failures.  Stream
   Control Transmission Protocol was developed to take full advantage of
   such a multi-homed host to provide a fast failover and association
   survivability in the face of such hardware failures.  However, many
   modern computers allow for the dynamic addition and deletion of
   network cards (sometimes termed a hot-pluggable interface). 
   Complicate this with the ability of a provider, in IPv6, to
   dynamically renumber a network, and there still is a gap between
   full-fault tolerance and the currently defined SCTP protocol.  No
   matter if a card is added or an interface is renumbered, in order to
   take advantage of this new configuration, the transport association
   must be restarted.  For many fault-tolerant applications this restart
   is considered an outage and is undesirable.

   Stream Control Transmission Protocol (SCTP) Dynamic Address
   Reconfiguration [RFC4960] [RFC5061] is an extension to SCTP to
   attempt to correct this problem for the more demanding fault-tolerant
   application.  This extension will allow an SCTP stack to:

   o  Dynamically add an IP address to an association.

   o  Dynamically delete an IP address from an association.

   o  Request to set the primary address the peer will use when sending
      to an endpoint.

   The dynamic addition and subtraction of IP addresses allows an SCTP
   association to continue to function through host and network
   reconfigurations.  These changes, brought on by provider or user
   action, may mean that the peer would be better served by using the
   newly added address; however, this information may only be known by]
   the endpoint that had the reconfiguration occur.  In such a case this
   extension allows the local endpoint to advise the peer as to what it
   thinks is the better primary address that the peer should be using.

   One last thing this extension adds is a small, 32-bit integer called
   an adaptation indication that can be exchanged at startup.  This is
 


Gao                      Expires April 17, 2020                [Page 17]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   useful for applications where there are one or more specific layers
   below the application, yet still above SCTP.  In such a case, the
   exchange of this indication can allow the proper layer to be enabled
   below the application.

3.3. Multipath TCP

   Seamless TCP mobility using lightweight MPTCP proxy [HAMPEL] utilizes
   Multipath TCP (MPTCP) [RFC6824] to implement a TCP mobility solution.
   However, Analysis of Residual Threats and Possible Fixes for
   Multipath TCP found some security issues such as ADD_ADDR attack.
   Hence inherent security of MPTCP is rather doubtful.

3.4. REST Architecture Style

   REST stands for "Representational State Transfer" [RESTful]. The name
   is intended to evoke an image of how a well-designed Web application
   behaves: a network of Web pages forms a virtual state machine,
   allowing a user to progress through the application by selecting a
   link or submitting a short data-entry form, with each action
   resulting in a transition to the next state of the application by
   transferring a representation of that state to the user.

   The REST architectural style consists of a set of architectural
   constraints chosen for the properties they induce on candidate
   architectures. For purpose of discussing mobility support we note
   that the first constraints added to the hybrid style are those of the
   client-server architectural style (CS). Separation of concerns is the
   principle behind the client-server constraints. CS style is closely
   followed by the client-stateless-server (CSS) style, such that each
   request from client to server must contain all of the information
   necessary to understand the request, and cannot take advantage of any
   stored context on the server. Session state is therefore kept
   entirely on the client. Communication must be stateless in nature.

   It is observable that REST architecture style, or RESTful pattern
   provides some degree of mobility support at the application layer.

   There are abundant Web applications that rely on HTTP which are built
   upon RESTful pattern. The Hypertext Transfer Protocol (HTTP)
   [RFC1945] [RFC7230] [RFC7540] is a request/response protocol.  A
   client sends a request containing request headers that specify the
   request method, URI, HTTP version, information about the client, some
   additional information about the request, and optional application
   data.  The server responds with a status or error code followed by a
   message containing information about the server and information about
   the data.  This may include a message body.

 


Gao                      Expires April 17, 2020                [Page 18]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   The browser that accesses the Web application built upon RESTful
   pattern may change its transport layer address freely, not to mention
   IP address, provided that each request from the browser contains all
   of the information necessary to understand the request and the
   browser can resolve the latest address of the server, as the
   communication is stateless in nature if it obeys RESTful pattern.
   Thus we conclude that REST architecture style inherently provides
   mobility support.








































 


Gao                      Expires April 17, 2020                [Page 19]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


4. A Solution at the Origin of the Problem

4.1. Separation of Identity and Locator at Transport Layer

   Why we design a new transport protocol to solve the routing
   scalability problem while provide mobility and multihoming support?
   Because it is the dominating transport layer protocols, TCP and UDP
   that take use of the IP address to identifying the end node,
   introduce the controversial role of IP address both as the identifier
   and as the routing locator.

   FSP is meant to be transport layer protocol that keeps the IP address
   as the routing locator but keeps it from being the key constituent of
   the FSP identifier or any upper layer protocol built upon FSP. It is
   a solution to avoid, if not to extirpate, the routing scalability
   problem.

4.2. Adding Programmer-Friendly Session Semantics

   It is hard to achieve the goal of making a new transport protocol
   accepted by the programmers. The service provided by the transport
   protocol should have some 'killer' features. FSP assumes that session
   semantics is such a feature.

   Here we define a session is a bundle of connections or streams that
   share the same authentication and authorization context.

4.2.1. Intuitiveness

   This concept is inspired by HTTP persistent connection. The
   persistent connections of HTTP 1.1 [RFC7230] and HTTP 2.0 [RFC7540]
   allow multiple request/response transactions (streams) during the
   lifetime of a single HTTP connection.  This reduces overhead during
   connection establishment and mitigates transport-layer slow-start
   that would have otherwise been incurred for each transaction.  HTTP
   2.0 connections can multiplex many request/response pairs in parallel
   on a single transport connection.  Both are important to reduce
   latency for HTTP's primary use case.

   These multiple request/response pairs, or streams in parallel,
   constitute a session.  Usually they share the same authentication and
   authorization context.  From a programmer's point of view they
   constitute a session.  

   It is much more intuitive (and more efficient) than to save the user
   authentication and authorization state in some representation form at
   the client side and transfer the state in representation form along
   with each request to the server side for authorization purpose.
 


Gao                      Expires April 17, 2020                [Page 20]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


4.2.2. Really Parallel Streams

   There is head-of-line congestion in HTTP persistent connection. Such
   head-of-line congestion is anti-intuitive and should be avoided.
   Connection Multiplication mechanism is meant to solve such head-of-
   line congestion problem. Connection multiplication makes a branch
   connection reuse the security context of the master connection and
   makes the new connection established in zero round trip.

   As per [RFC8108] an endpoint may send multiple RTP streams in a
   single RTP session. FSP is meant to cover such requirement as well.

4.2.3. Mixed Traffic Class

   A real world application may consist mixed traffic classes of
   streams, for example one control stream which does not tolerate
   packet loss, and a bundle of streams that carry payloads favoring
   low-latency while tolerating packet loss. All these streams belong to
   the same session in the sense of same user authentication and
   authorization context.

4.2.4. Session Adjournment and Resumption

   It is not uncommon for an application to exploit TCP as the transport
   protocol, and as TCP transmits the application data as an unbroken
   stream of octets it is at the application layer to delimiter the
   messages that are sent continually. 

   It would be convenient if the application data could still be sent in
   stream mode and the transport service provides the 'commit'
   programming interface, through which the application can explicitly
   set the transmission check point where further sending of data is
   prohibited until all of the data sent have been acknowledged at the
   transport layer.

   It is considered a weak, asymmetric, yet essential requirement for
   session adjournment and resumption. FSP provides Transmit Transaction
   mechanism to fulfill such requirement.

4.3. Adding Programmer-friendly Security Service

4.3.1. Ubiquitous Encryption and Authentication of Data

   As revealed in "Datagram Transport Layer Security" (DTLS) [RFC6347]
   even client/server applications that takes use of UDP needs to
   communicate in a way that manages to prevent eavesdropping,
   tampering, or message forgery. Transport layer protocol should
   provide inherent support for ubiquitous encryption and/or
 


Gao                      Expires April 17, 2020                [Page 21]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   authentication of data.

4.3.2. Key Establishment versus Application of Keys

   IPsec architecture [RFC4301] clearly separates the sub-protocol for
   key establishment through Internet Key Exchange (IKE) [RFC7296], and
   the sub-protocol for applying the established key through the
   Authentication Header (AH) [RFC4302] and Encapsulating Security
   Payload (ESP) [RFC4303].

   However, as the mechanism of security association (SA) is stateful it
   is not convenient to solve the problems at the IP layer which should
   better be stateless for sake of scalability.

   Besides, as the IP layer services are often implemented in the kernel
   of the operating systems the extensibility is limited, but various
   classes of applications often require variable key establishment
   process that could be directly managed by the end-node application.

   It would be convenient if the key established at the application
   layer could be applied at the transport layer to encrypt the payload
   with authentication.

5. Choices of Design Goals

5.1. Featured Scenarios

5.1.1. Goal: Support for Mobile Computing

   As stated in 'Report from the IAB Workshop on Routing and
   Addressing', September 2007 [RFC4984], 'The workshop participants
   recognized that the increase in the number of mobile devices can be
   significant, and that if a scalable routing system supporting generic
   identity-locator separation were developed and introduced, billions
   of mobile gadgets could be supported without bringing undue impact on
   global routing scalability and stability'.

   FSP can be implemented in the user-space of the operating systems. It
   is technically feasible to deploy FSP-dependent applications as the
   Software-as-a-Service [SaaS] on the public cloud computing platform
   and distribute the FSP-enabled client applications that act as the
   agents of the SaaS platform through some online application store to
   serve more than ever mobile users. It has high probability of earning
   economical benefit to deploy such solution because FSP consume
   considerably less computing resource than TLS over TCP or DTLS over
   UDP.

   Unlike the help desks of the enterprise networks the public cloud
 


Gao                      Expires April 17, 2020                [Page 22]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   service providers and the wireless communication service providers
   can be much more tolerant with the new transport protocol. 

5.1.2. Goal: Adaptable to Specific-Purpose Networks

   Here specific-purpose networks mean those networks that dedicatedly
   serve for some special purpose, such as Storage Area Network (SAN) at
   which Internet Small Computer Systems Interface (iSCSI) [RFC7143] is
   targeted.

   Such specific-purpose networks often favor high performance over
   privacy. It may find it is overkill to utilize FSP. However in such
   scenario the weak integrity protection mode that utilize CRC64
   [CRC64] may be exploited, where CRC64 calculation may be implemented
   in commoditized hardware. High-performance software implementation
   exists as well.

   And it should be feasible to realize FSP directly over layer 2
   jumbogram packet switch network in some specific-purpose network such
   as at the data center of the cloud service provider.

   It should be feasibility to exploit hardware acceleration for FSP in
   the specific-purpose networks.

5.1.3. Goal: Adaptable to Constrained-Node Networks

   As defined in [RFC7228], a constrained-node network is a network
   whose characteristics are influenced by being composed of a
   significant portion of constrained nodes. A constrained-node network
   always is a constrained network because of the network constraints
   stemming from the node constraints. In the constrained network some
   of the characteristics pretty much taken for granted with link layers
   in common use in the Internet at the time of writing are not
   attainable, such as in the LLN (as described in Terms Used in Routing
   for Low-Power and Lossy Networks [RFC7102]).

   It is observed that key establishment almost always consumes much
   more CPU power and/or RAM resource than data encryption/decryption
   that applying the key, per octet transmitted in the network.

   FSP is designed to support persistent session, where it is possible
   to establish the connection securely between the constrained node and
   its more powerful peer during the provisioning phase, and keep the
   connection secure with the automatic re-keying mechanism, while the
   upper layer application is able to do transactional works by
   exploiting transmit transaction mechanism provided by FSP. The
   session key to be established may even be negotiated with some
   additional hardware acceleration attached to the constrained node at
 


Gao                      Expires April 17, 2020                [Page 23]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   the provision phase.

5.1.4. Non-Goal: General Multicast Transport

   Although there is some trace of supporting 'duplicate-cast' which
   means sending to two, at most three receivers in design of FSP,
   Duplication-cast Extensibility is yet to be studied. General
   multicast support is simply non-goal.


5.2. Optimizing towards IPv6

5.2.1. Goal: Promoting Transition towards IPv6

   FSP is intent on promoting IPv6 for sake of transparent end-to-end
   connectivity.

5.2.2. Goal: NAT friendliness in IPv4 network

   Network Address Translation and Port Translation (NAPT) [RFC2663]
   works well for conserving global addresses and addressing multihoming
   requirements because an IPv4 NAPT router implements three functions:
   source address selection, next-hop resolution, and (optionally) DNS
   resolution. It is mandatory for FSP to keep NAT-friendliness in the
   IPv4 internetwork because NAT middleboxes are ubiquitous.

5.2.3. Non-Goal: NAT friendliness in IPv6 network

   It is both feasible and preferable to avoid NAT in the IPv6
   internetwork for sake of transparent end-to-end connectivity.

5.3. Congestion Control

5.3.1. Goal: ECN Awareness

   The Benefits of Using Explicit Congestion Notification (ECN)
   [RFC8087] outlines the principal gains in terms of increased
   throughput, reduced delay, and other benefits when ECN is used over a
   network path that includes equipment that supports Congestion
   Experienced (CE) marking.

   FSP should take advantages of ECN [RFC3168].

5.3.2. Goal: Host-Aggregated Congestion Control

   We argue that congestion control should be end-to-end at the network
   layer instead of transport layer. All traffic between two network
   nodes shall be subjected aggregately to the congestion control.
 


Gao                      Expires April 17, 2020                [Page 24]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


5.3.3. Goal: Congestion Control Per Traffic Class

   As it is a designed feature for FSP to carry mixed traffic class in
   one session, but there is no single congestion control mechanism will
   work for all traffic classes, it would be convenient that different
   traffic class is treated with different congestion control mechanism.

5.3.4. Debatable: TCP Friendliness

   It is observable that traffics such as multi-thread downloading or
   video-streaming over RTP [RFC3550] that manage to avoid TCP
   congestion control are overwhelmingly increasing. It might be too
   conservative to keep up with such application trends to obey with
   TCP-friendliness.

5.4. Infrastructure Independency

   FSP does not introduce any new namespace, nor does it depend on new
   network infrastructure. However it does make some assumption about
   the network layer infrastructure.

5.4.1. Goal: More Efficient Use of the IPv6 Address Space

   The length of an IPv6 address is 128 bits. Practices of IPv6 NAPT
   show that address space of 48 bits is sufficient. There could be
   optimization space for more efficient use of the IPv6 address space.

   o Every IPv6 network node is effectively a router

     And it could be argued that this opinion is implicitly supported by
     "Unique IPv6 Prefix per Host" [RFC8273].

   o The upper layer application is the ultimate IPv6 end-point

     Again, it could be argued that this opinion is implicitly supported
     by "Unique IPv6 Prefix per Host".

5.4.2. Goal: ECN Awareness

   FSP should take advantages of ECN, which is a network infrastructure
   mechanism.

5.4.3. Non-Goal: Inventing New Rendezvous Mechanism

   FSP should take advantages of Dynamic DNS [RFC2136] to provide
   rendezvous mechanism in case that the two participants change their
   IP addresses simultaneously. It does not intent to re-invent the
   wheel.
 


Gao                      Expires April 17, 2020                [Page 25]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


5.5. Feasibility of Hardware Acceleration

5.5.1. Goal: Hardware-Accelerated Cryptography

   Hardware implementation efficiency and popularity shall be the most
   important factors of selecting the data integrity and confidentiality
   protection algorithm.

   First version of FSP exploits AES-GCM [AES][GCM], liking in The Use
   of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload
   (ESP) [RFC4106].

   Here it is explicitly proposed that the upper layer application
   should take care of key establishment, and install the key
   established onto the FSP layer, alike to the Use of Channel Bindings
   to Secure Channels [RFC5056]. Reason behind the proposal is alike to
   channel binding as well: 'the main goal of channel binding is to be
   able to delegate cryptographic session protection to network layers
   below the application in hopes of being able to better leverage
   hardware implementations of cryptographic protocols'.

5.5.2. Goal: Hardware-assisted Header Processing

   FSP chooses to design fixed-size header for normal packet that
   imitates Reduced Instruction Set Computer (RISC) instructions that
   are easier to process in hardware.

5.6. QoS and Multipath Issues

5.6.1. Goal: Minimal Delay Service for Milk Like Payload

   An ordinary data flow is wine-like in the sense that the older data
   are more valuable. If it has to, data packet sent latest are dropped
   first. In the contrary, milk-like payload is that the newer data are
   more precious and outdated data packet can be discarded.

   FSP is designed to support mixed traffic class that providing service
   both for wine-like payload and milk-like payload.

5.6.2. To be studied: Resource Reservation

   End-to-End resource reservation protocol packets MAY be piggybacked
   on the preliminary FSP packets that are exchanged in the connection
   establishment process to provide guaranteed quality of service.
   However as resource reservation [RFC2205] requires that the network
   layer nodes along the path that the protocol packets have passed to
   keep some state, the scalability is questionable.

 


Gao                      Expires April 17, 2020                [Page 26]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   However, since resource reservation may assure higher quality of
   service, future version of FSP should be capable of reserving
   resource along the network path in the connection establishment
   process, at least for some special purpose network.

5.6.3. To be studied: PMTU Discovery

   For sake of maximizing mobility and multi-path support it is not
   required to implement Packetization Layer Path MTU Discovery
   [RFC4821] for FSP.

   PMTU may be discovered together with resource reservation in the
   future.

5.7. On-the-wire Compression

   Because lots of content is compressible and compression saves
   bandwidth, it is proposed that FSP shall support on-the-wire
   compression.

   LZ4 algorithm is chosen for it "features extremely fast decoder"
   [LZ4]. Few well-known loss-less compression algorithm has higher
   performance than LZ4 (in according to [LZTURBO]) in terms of
   decompression speed. The apparent one exception, LzTurbo, has not yet
   open-sourced.

   Besides, LZ4 offers a high compression derivative called LZ4_HC that
   shares the same "extremely fast decoder" with the default compressor.
   It is possible to pre-compress some content with LZ4_HC and serve it
   to mass client, while each client decodes and gets the original
   content with on-the-wire speed.

5.7.1. Goal: Compatibility with Pre-compression

   From the sender side of view lots of content is pre-determined and
   pre-compressible. It would be welcomed if the on-the-wire compression
   algorithm chosen offers a high compression branch that share the same
   on-the-wire speed decoder with the on-the-wire encoder.

5.7.2. Goal: Decompression Speed

   The decoder should run as fast as possible.

5.7.3. Goal: System Robustness

   From the receiver point of view decompression may consume
   unpredictable amount of memory resource. On-the-wire compression
   service SHOULD be provided in the user space for sake of system
 


Gao                      Expires April 17, 2020                [Page 27]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   robustness. And the decoder should consume memory resource less than
   the amount reasonably provided by a constrained node.

5.7.4. Non-Goal: Versatility of On-the-Wire Compression

   Speed should take precedence over compression ratio on selecting the
   on-the-wire compression algorithm for FSP.


6. Security Considerations

   FSP MUST provide mechanism to fight against connection hi-jack
   attack.

   FSP SHALL provide data encryption and decryption mechanism to protect
   confidentiality of the payload

   For sake of performance FSP chooses symmetric-key algorithm to
   achieve the goal. In the first version of FSP slightly modified
   AEAD_AES_128_GCM or AEAD_AES_256_GCM [RFC5116] is applied.

   FSP SHALL provide data integrity protection mechanism. In the first
   version Authenticated Encryption with Associated Data [R02] algorithm
   AES-GCM is applied to protect integrity of each FSP packet, unless
   the upper layer application explicitly relaxes the requirement. 

   FSP does not intend to provide full-fledged cryptography support.
   Easy of use with reasonable flexibility takes precedence.

   It is explicitly proposed that the upper layer application should
   take care of key establishment, and install the key established onto
   the FSP layer.

7. IANA Considerations

   This document has no actions for IANA.

8. References

8.1. Normative References

   [MinimaLT] W. Michael Petullo, Xu Zhang, Jon A. Solworth, Daniel J.
              Bernstein, Tanja Lange. MinimaLT: Minimal-latency
              networking through better security, October 2013,
              <http://cr.yp.to/tcpip/minimalt-20131031.pdf> 

   [R02]      Rogaway, P., "Authenticated encryption with Associated-
              Data", ACM Conference on Computer and Communication
 


Gao                      Expires April 17, 2020                [Page 28]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


              Security (CCS'02), pp. 98-107, ACM Press, 2002,
              <http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>.

   [RESTful]  Fielding R. T. and R. N. Taylor, "Principled Design of the
              Modern Web Architecture", International Conference on
              Software Engineering, 2000: 407-416.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

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

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,
              <https://www.rfc-editor.org/info/rfc2663>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, DOI 10.17487/RFC3963, January 2005,
              <https://www.rfc-editor.org/info/rfc3963>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May
              2006, <https://www.rfc-editor.org/info/rfc4423>.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
              <https://www.rfc-editor.org/info/rfc5056>.

 


Gao                      Expires April 17, 2020                [Page 29]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, DOI 10.17487/RFC5380, October 2008,
              <https://www.rfc-editor.org/info/rfc5380>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC6740]  RJ Atkinson and SN Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740, DOI
              10.17487/RFC6740, November 2012, <https://www.rfc-
              editor.org/info/rfc6740>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830, DOI
              10.17487/RFC6830, January 2013, <https://www.rfc-
              editor.org/info/rfc6830>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
              Korhonen, "Requirements for Distributed Mobility
              Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
              <https://www.rfc-editor.org/info/rfc7333>.

   [RFC8004]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004,
              October 2016, <https://www.rfc-editor.org/info/rfc8004>.

   [RFC8046]  Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
              with the Host Identity Protocol", RFC 8046, DOI
              10.17487/RFC8046, February 2017, <https://www.rfc-
              editor.org/info/rfc8046>.

 


Gao                      Expires April 17, 2020                [Page 30]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   [RFC8087]  Fairhurst, G. and M. Welzl, "The Benefits of Using
              Explicit Congestion Notification (ECN)", RFC 8087, DOI
              10.17487/RFC8087, March 2017, <https://www.rfc-
              editor.org/info/rfc8087>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200, DOI
              10.17487/RFC8200, July 2017, <https://www.rfc-
              editor.org/info/rfc8200>.

   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
              <https://www.rfc-editor.org/info/rfc8273>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.


8.2. Informative References

   [AES]      NIST, "Advanced Encryption Standard (AES)", November 2001.
              <https://doi.org/10.6028/NIST.FIPS.197>

   [CRC64]    ECMA, "Data Interchange on 12.7 mm 48-Track Magnetic Tape
              Cartridges - DLT1 Format Standard, Annex B", ECMA-182,
              December 1992.

   [GCM]      NIST, "Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC", November 2007.
              <http://dx.doi.org/10.6028/NIST.SP.800-38D>

   [HAMPEL]   Hampel, G., Rana, A., and T. Klein, "Seamless TCP mobility
              using lightweight MPTCP proxy", MobiWac '13: Proceedings
              of the 11th ACM international symposium on Mobility
              management and wireless access, DOI
              10.1145/2508222.2508226, November 2013.

   [LOCATING-USER]
              Kirby, G., "Locating the User", Communications
              International, 1995.

   [LZ4]      https://lz4.github.io/lz4/
 


Gao                      Expires April 17, 2020                [Page 31]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   [LZTURBO]  https://github.com/powturbo/TurboBench

   [SaaS]     Peter, M. and G. Tim, "The NIST Definition of Cloud
              Computing", SP 800-145, September 2011,
              <https://doi.org/10.6028/NIST.SP.800-145>

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, DOI 10.17487/RFC1498, August
              1993, <https://www.rfc-editor.org/info/rfc1498>.

   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
              Transfer Protocol -- HTTP/1.0", RFC 1945, DOI
              10.17487/RFC1945, May 1996, <https://www.rfc-
              editor.org/info/rfc1945>.

   [RFC2101]  Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
              Address Behaviour Today", RFC 2101, DOI 10.17487/RFC2101,
              February 1997, <https://www.rfc-editor.org/info/rfc2101>.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC2956]  Kaat, M., "Overview of 1999 IAB Network Layer Workshop",
              RFC 2956, DOI 10.17487/RFC2956, October 2000,
              <https://www.rfc-editor.org/info/rfc2956>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              RFC 4106, DOI 10.17487/RFC4106, June 2005,
              <https://www.rfc-editor.org/info/rfc4106>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4297]  Romanow, A., Mogul, J., Talpey, T., and S. Bailey, "Remote
              Direct Memory Access (RDMA) over IP Problem Statement",
              RFC 4297, DOI 10.17487/RFC4297, December 2005,
              <https://www.rfc-editor.org/info/rfc4297>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, DOI
 


Gao                      Expires April 17, 2020                [Page 32]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


              10.17487/RFC4302, December 2005, <https://www.rfc-
              editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, DOI
              10.17487/RFC4422, June 2006, <https://www.rfc-
              editor.org/info/rfc4422>.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
              <https://www.rfc-editor.org/info/rfc4555>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <https://www.rfc-editor.org/info/rfc4821>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
              editor.org/info/rfc4861>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC4984]  Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
              from the IAB Workshop on Routing and Addressing",
              RFC 4984, DOI 10.17487/RFC4984, September 2007,
              <https://www.rfc-editor.org/info/rfc4984>.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
              Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
              <https://www.rfc-editor.org/info/rfc5056>.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061, DOI
              10.17487/RFC5061, September 2007, <https://www.rfc-
              editor.org/info/rfc5061>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

 


Gao                      Expires April 17, 2020                [Page 33]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   [RFC5218]  Thaler, D. and B. Aboba, "What Makes for a Successful
              Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
              <https://www.rfc-editor.org/info/rfc5218>.

   [RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
              Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
              DOI 10.17487/RFC5723, January 2010, <https://www.rfc-
              editor.org/info/rfc5723>.

   [RFC5889]  Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing
              Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889,
              September 2010, <https://www.rfc-editor.org/info/rfc5889>.

   [RFC5942]  Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
              Model: The Relationship between Links and Subnet
              Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010,
              <https://www.rfc-editor.org/info/rfc5942>.

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, DOI 10.17487/RFC5944, November 2010,
              <https://www.rfc-editor.org/info/rfc5944>.

   [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address
              Assignment to End Sites", BCP 157, RFC 6177, DOI
              10.17487/RFC6177, March 2011, <https://www.rfc-
              editor.org/info/rfc6177>.

   [RFC6250]  Thaler, D., "Evolution of the IP Model", RFC 6250, DOI
              10.17487/RFC6250, May 2011, <https://www.rfc-
              editor.org/info/rfc6250>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC6741]  RJ Atkinson and SN Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Engineering Considerations", RFC 6741, DOI
              10.17487/RFC6741, November 2012, <https://www.rfc-
              editor.org/info/rfc6741>.

   [RFC6742]  RJ Atkinson, SN Bhatti, and S. Rose, "DNS Resource Records
              for the Identifier-Locator Network Protocol (ILNP)",
              RFC 6742, DOI 10.17487/RFC6742, November 2012,
              <https://www.rfc-editor.org/info/rfc6742>.
 


Gao                      Expires April 17, 2020                [Page 34]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


   [RFC6743]  RJ Atkinson and SN Bhatti, "ICMP Locator Update Message
              for the Identifier-Locator Network Protocol for IPv6
              (ILNPv6)", RFC 6743, DOI 10.17487/RFC6743, November 2012,
              <https://www.rfc-editor.org/info/rfc6743>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832, DOI
              10.17487/RFC6832, January 2013, <https://www.rfc-
              editor.org/info/rfc6832>.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833, DOI
              10.17487/RFC6833, January 2013, <https://www.rfc-
              editor.org/info/rfc6833>.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
              January 2013, <https://www.rfc-editor.org/info/rfc6836>.

   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
              2014, <https://www.rfc-editor.org/info/rfc7102>.

   [RFC7143]  Chadalapaka, M., Satran, J., Meth, K., and D. Black,
              "Internet Small Computer System Interface (iSCSI) Protocol
              (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April
              2014, <https://www.rfc-editor.org/info/rfc7143>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, DOI
              10.17487/RFC7228, May 2014, <https://www.rfc-
              editor.org/info/rfc7228>.

   [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Semantics and Content",
              RFC 7231, DOI 10.17487/RFC7231, June 2014,
 


Gao                      Expires April 17, 2020                [Page 35]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC7402]  Jokela, P., Moskowitz, R., and J. Melen, "Using the
              Encapsulating Security Payload (ESP) Transport Format with
              the Host Identity Protocol (HIP)", RFC 7402, DOI
              10.17487/RFC7402, April 2015, <https://www.rfc-
              editor.org/info/rfc7402>.

   [RFC7429]  Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
              CJ. Bernardos, "Distributed Mobility Management: Current
              Practices and Gap Analysis", RFC 7429, DOI
              10.17487/RFC7429, January 2015, <https://www.rfc-
              editor.org/info/rfc7429>.

   [RFC7430]  Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
              Raiciu, "Analysis of Residual Threats and Possible Fixes
              for Multipath TCP (MPTCP)", RFC 7430, DOI
              10.17487/RFC7430, July 2015, <https://www.rfc-
              editor.org/info/rfc7430>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI
              10.17487/RFC7540, May 2015, <https://www.rfc-
              editor.org/info/rfc7540>.

   [RFC7608]  Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
              Length Recommendation for Forwarding", BCP 198, RFC 7608,
              DOI 10.17487/RFC7608, July 2015, <https://www.rfc-
              editor.org/info/rfc7608>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
 


Gao                      Expires April 17, 2020                [Page 36]

INTERNET DRAFT             Motivations of FSP           October 15, 2019


              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.rfc-editor.org/info/rfc7721>.

   [RFC7925]  Tschofenig, H., Ed., and T. Fossati, "Transport Layer
              Security (TLS) / Datagram Transport Layer Security (DTLS)
              Profiles for the Internet of Things", RFC 7925, DOI
              10.17487/RFC7925, July 2016, <https://www.rfc-
              editor.org/info/rfc7925>.

   [RFC8108]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
              "Sending Multiple RTP Streams in a Single RTP Session",
              RFC 8108, DOI 10.17487/RFC8108, March 2017,
              <https://www.rfc-editor.org/info/rfc8108>.

   [RFC8170]  Thaler, D., Ed., "Planning for Protocol Adoption and
              Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
              May 2017, <https://www.rfc-editor.org/info/rfc8170>.



Author's Address


      Jun-an Gao
      Beijing Capital Highway Development Group Co.,Ltd.
      Shoufa Plaza-A, Liuliqiao South, Fengtai
      Beijing
      People's Republic of China

      EMail: jagao@outlook.com





















Gao                      Expires April 17, 2020                [Page 37]