[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                         T. Murakami, Ed.
Internet-Draft                                               Arrcus, Inc
Intended status: Informational                             S. Matsushima
Expires: September 6, 2020                                      SoftBank
                                                              K. Ebisawa
                                                Toyota Motor Corporation
                                                               P. Garvia
                                                              R. Shekhar
                                                     Cisco Systems, Inc.
                                                           March 5, 2020


                      User Plane Message Encoding
           draft-murakami-dmm-user-plane-message-encoding-01

Abstract

   This document defines the encoding of User Plane messages into
   Segment Routing Header (SRH).  The SRH carries the User Plane
   messages over SRv6 Network.

Status of This Memo

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

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

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

   This Internet-Draft will expire on September 6, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Murakami, et al.        Expires September 6, 2020               [Page 1]


Internet-Draft         user-plane-message-encoding            March 2020


   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   4.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  User Plane Message encoding into SRH  . . . . . . . . . . . .   3
     5.1.  GTP-U Header format . . . . . . . . . . . . . . . . . . .   4
     5.2.  Args.Mob.Upmsg  . . . . . . . . . . . . . . . . . . . . .   4
     5.3.  Encoding of Tags Field  . . . . . . . . . . . . . . . . .   5
     5.4.  User Plane message Information Element Support  . . . . .   6
     5.5.  SID flavor consideration  . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   3GPP defines User Plane messages.  The User Plane messages support
   in-band signaling for path and tunnel management.  Currently, User
   Plane messages are defined in TS 29.281 [TS29281].

   When applying SRv6 (Segment Routing IPv6) to the user plane of mobile
   networks based on draft-ietf-dmm-srv6-mobile-uplane
   [I-D.ietf-dmm-srv6-mobile-uplane], User Plane messages must be
   carried over SRv6 network.  This document defines which User Plane
   message must be encoded to SRv6 and also defines how to encode the
   User Plane messages into SRH.

   In addition, SRH is mandatory at the ultimate segment upon carrying
   the User Plane messages because User Plane message is encoded into
   SRH.  Hence, this document considers how to deal with the encoding of
   User Plane messages into SRH when PSP is applied that SRH is popped
   out at the penultimate segment.








Murakami, et al.        Expires September 6, 2020               [Page 2]


Internet-Draft         user-plane-message-encoding            March 2020


2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Conventions and Terminology

   SRv6:                 Segment Routing IPv6.

   GTP-U:                GPRS Tunneling Protocol User Plane.

   UPF:                  User Plane Function.

   SRH:                  IPv6 Segment Routing Header.

   PSP:                  Penultimate Segment POP of the SRH.

   USP:                  Ultimate Segment Pop of the SRH.

4.  Motivation

   3GPP User Plane needs to support the user plane messages associated
   with a GTP-U tunnel defined in [TS29281].  In the case of SRv6 User
   Plane [I-D.ietf-dmm-srv6-mobile-uplane], those messages are also
   required when the user plane interworks with GTP-U.

   Segment Routing Header (SRH) [I-D.ietf-6man-segment-routing-header]
   is used for SRv6 User Plane.  SRH is able to associate additional
   information to the segments.  The Tag field of SRH is capable to
   indicate different properties within a SID.  SRH TLV is capable to
   provide meta-data to the endpoint node.

   The above capability of SRH motivates us to map the user plane
   messages into it because of the same encapsulation with the packets
   of carrying client packets.  It introduces no additional headers or
   extension headers to be chained in the packet just for carrying the
   user plane messages.

5.  User Plane Message encoding into SRH

   This section defines how to encode the User Plane messages into SRH
   in order to carry the User Plane messages over SRv6 network.








Murakami, et al.        Expires September 6, 2020               [Page 3]


Internet-Draft         user-plane-message-encoding            March 2020


5.1.  GTP-U Header format

   3GPP defines GTP-U Header format as shown below.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Ver |P|R|E|S|N| Message Type  |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Tunnel Endpoint Identifier                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Sequence Number          | N-PDU Number  |  Next-Ext-Hdr |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: GTP-U Header format

   User Plane message type is encoded in Message Type field of GTP-U
   Header.  The following User Plane messages must be carried over SRv6
   network at least.  The value of each User Plane message type is
   defined as shown below.

   Echo Request:       1

   Echo Reply:         2

   Error Indication:   26

   End Marker:         254

5.2.  Args.Mob.Upmsg

   draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane]
   defines the format of Args.Mob.Session argument which is used in SRv6
   SID Mobility Functions in order to carry the PDU Session identifier.
   The format of Args.Mobs.Session is defined as shown below.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   QFI     |R|U|                PDU Session ID                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |PDU Sess(cont')|
       +-+-+-+-+-+-+-+-+

                     Figure 2: Args.Mob.Session format

   In case of Echo Request, Echo Reply and Error Indication, Sequence
   Number in GTP-U header needs to be carried.  Similar to draft-ietf-



Murakami, et al.        Expires September 6, 2020               [Page 4]


Internet-Draft         user-plane-message-encoding            March 2020


   dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane], the new
   arguments to carry Sequqnce number for Echo Request, Echo Reply and
   Error Indication message needs to be defined.  For this, the
   following Args.Mobs.Upmsg should be defined newly to carry Sequence
   number.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   QFI     |R|U|       Sequence Number         |      Pad      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Pad(cont')  |
       +-+-+-+-+-+-+-+-+

     Figure 3: Args.Mob.Upmsg format for Echo Request, Echo Reply and
                             Error Indication

   QFI bit, R bit, U bit and 16-bit Sequence Number is encoded in
   Args.Mobs.Upmsg.  The remaining bits followed by Sequence Number must
   be padded in 0.

   In case of End Marker, TEID shall be used as PDU Session ID same as
   draft-ietf-dmm-srv6-mobile-uplane [I-D.ietf-dmm-srv6-mobile-uplane].
   Hence, for End Marker, Args.Mobs.Session should be used to carry TEID
   as PDU Session ID.

5.3.  Encoding of Tags Field

   The Segment Routing Header is defined in draft-ietf-6man-segment-
   routing-header [I-D.ietf-6man-segment-routing-header].  This draft
   defines 16 bits Tag field but does not define the format or use of
   this Tag field in the Segment Routing Header.

   The User Plane message type encoding is defined in TS 29.281
   [TS29281].  Based on this definition, the User Plane message type
   must be encoded into the Tag field in the Segment Routing Header in
   order to indicate the type of the user plane messages for at least
   Echo Request, Echo Reply, Error Indication or End Marker.

   Only UPF must process the Tag field where the user plane message is
   encoded.  In addition, when the user plane message is encoded in the
   Tag field, the UPF should not encode any segments in the Segment
   Routing Header whose function modifies the Tag field value.  Any
   other transport router implementing SRv6 must ignore the Tag field
   upon processing the Segment Routing Header.

   The user plane messages must be encoded into the Tag filed as shown
   below.



Murakami, et al.        Expires September 6, 2020               [Page 5]


Internet-Draft         user-plane-message-encoding            March 2020


               0                             1
               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
               |         Reserved                  |B3|B2|B1|B0|
               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                       Figure 4: Tag Field Encoding

   Bit 0 [B0]:     End Marker

   Bit 1 [B1]:     Error Indication

   Bit 2 [B2]:     Echo Request

   Bit 3 [B3]:     Echo Reply

   End Marker, Echo Request and Echo reply messages do not require any
   additional information elements.  However, Error Indication message
   requires the additional information elements like Tunnel Endpoint
   Identifier Data IE, GSN Address, etc.  These additional information
   elements can be encoded into the SRH TLV that is defined in the next
   section.

5.4.  User Plane message Information Element Support

   End Maker, Echo Request and Echo Reply messages do not require any
   additional information elements.  However, Error Indication message
   requires additional 3GPP IEs (Information Element).  These additional
   information elements must be carried over SRv6 network as well.
   However SRv6 SID has limited space only.  Hence it cannot carry a lot
   of information elements.

   In order to carry more information elements, SRH TLV shall be
   leveraged.  SRH TLV is defined in draft-ietf-6man-segment-routing-
   header [I-D.ietf-6man-segment-routing-header] in order to carry the
   meta-data for the segment processing.  In order to carry additional
   User Plane messages like 3GPP IEs, the new type named as "User Plane
   Container" must be defined as the new SRH TLV.  The "User Plane
   Container" can carry additional User Plane messages which includes
   multiple 3GPP IEs with 1 sub-TLV.











Murakami, et al.        Expires September 6, 2020               [Page 6]


Internet-Draft         user-plane-message-encoding            March 2020


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |     Length      |  User Plane message sub-TLV |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //               User Plane message sub-TLV                    //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         User Plane Container TLV

   Type:           to be assigned by IANA

   Length:         Length of User Plane message sub-TLV

   User Plane message sub-TLV:   User Plane message sub-TLV defined
                   below

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |     Length      |            Value            //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        User Plane message sub-TLV

   Type:           Type of User Plane message sub-TLV



                   3GPP IE sub-TLV:        0x01

   Length:         Length of Value

   Value:          User Plane Message data



                   3GPP IE sub-TLV:        multiple 3GG IEs

5.5.  SID flavor consideration

   This section considers SID flavor of where the SRH is popped out at
   either the penultimate or the ultimate segment.

   In order to carry User Plane message over SRv6 network, SRH must be
   sustained over entire SRv6 network because User Plane message type
   and required information elements are encoded into SRH.  If the




Murakami, et al.        Expires September 6, 2020               [Page 7]


Internet-Draft         user-plane-message-encoding            March 2020


   penultimate segment is popping out SRH, i.e., PSP, User Plane message
   can not be carried in entire SRv6 network.

   In order to avoid this problem, USP is recommended in SRv6 Mobile
   network.  In this case, SRH is never popped out and User Plane
   message can be sustained over entire SRv6 network.

   However, if PSP needs to be enabled in SRv6 network, it is also a
   possible solution to encap another SRH which carries User Plane
   message along with the outer IPv6 or SRH.

6.  Security Considerations

   TBD

7.  IANA Consideration

   The type value of SRH TLV for User Plane Container must be assigned
   by IANA.

8.  Acknowledgements

9.  References

9.1.  Normative References

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

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

9.2.  Informative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
              progress), October 2019.





Murakami, et al.        Expires September 6, 2020               [Page 8]


Internet-Draft         user-plane-message-encoding            March 2020


   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
              Voyer, D., and C. Perkins, "Segment Routing IPv6 for
              Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07
              (work in progress), November 2019.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513,
              DOI 10.17487/RFC3513, April 2003,
              <https://www.rfc-editor.org/info/rfc3513>.

   [TS29281]  3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 2019,
              <http://www.3gpp.org/ftp//Specs/
              archive/29_series/29.281/29281-f60.zip>.

Authors' Addresses

   Tetsuya Murakami (editor)
   Arrcus, Inc
   2077 Gateway Place, Suite 400
   San Jose
   USA

   Email: tetsuya@arrcus.com


   Satoru Matsushima
   SoftBank
   1-9-1 Higashi-Shinbashi, Munato-ku
   Tokyo
   Japan

   Email: satoru.matsushima@g.softbank.co.jp


   Kentaro Ebisawa
   Toyota Motor Corporation
   Tokyo
   Japan

   Email: ebisawa@toyota-tokyo.tech




Murakami, et al.        Expires September 6, 2020               [Page 9]


Internet-Draft         user-plane-message-encoding            March 2020


   Pablo Camarillo Garvia
   Cisco Systems, Inc.
   Spain

   Email: pcamaril@cisco.com


   Ravi Shekhar
   Cisco Systems, Inc.
   USA

   Email: ravishek@cisco.com







































Murakami, et al.        Expires September 6, 2020              [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/