Internet DRAFT - draft-trossen-detnet-rsvp-tsn

draft-trossen-detnet-rsvp-tsn



 



DetNet Working Group                                          D. Trossen
INTERNET-DRAFT                                                    Huawei
Intended Status: Standards Track                             F.-J. Goetz
Expires: January 7, 2023                                      J. Schmitt
                                                                 Siemens
                                                            July 7, 2022


                         RSVP for TSN Networks
                  draft-trossen-detnet-rsvp-tsn-02.txt


Abstract

   This document provides a solution for control plane signaling by
   virtue of proposing changes to RSVP signaling with deterministic
   services at the underlying TSN enabled layer. The solution covers
   distributed, centralized, and hybrid signaling scenarios in the TSN
   and SDN domain. The proposed changes to RSVP IntServ, called RSVP TSN
   in the remainder of this document, provide a better integration with
   Layer 2 technologies for resource reservation, for which we outline
   example API specifications for the realization of RSVP TSN.     

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) 2020 IETF Trust and the persons identified as the
   document authors. All rights reserved.
 


Trossen, et al.          Expires July 11, 2022                  [Page 1]

INTERNET DRAFT           RSVP for TSN Networks                          


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  RSVP IntServ vs RSVP TSN Data Plane Model  . . . . . . . .  6
     3.2.  RSVP IntServ vs RSVP TSN Resource Reservation Styles . . .  6
     3.3.  RSVP IntServ vs RSVP TSN Object Definitions  . . . . . . .  7
     3.4 RSVP IntServ vs RSVP TSN Flow Specification  . . . . . . . .  7
   4.  RSVP TSN . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Layer Interactions between RSVP TSN and Lower Layer 
           Resource Allocation  . . . . . . . . . . . . . . . . . . .  9
     4.2.  API for Deterministic QoS (dQoS) . . . . . . . . . . . . . 10
     4.3.  DnFlow Signaling Interface (DnFSI) . . . . . . . . . . . . 10
     4.4.  DnFlow Transport Interface (DnFTI) . . . . . . . . . . . . 13
     4.5.  RSVP TSN Message Formats . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15














 


Trossen, et al.          Expires July 11, 2022                  [Page 2]

INTERNET DRAFT           RSVP for TSN Networks                          


1.  Introduction

   The authors in [ID.malis-detnet-controller-plane-framework] provide
   an overview of the DetNet control plane architecture along three
   possible classes, namely (i) fully distributed control plane
   utilizing dynamic signaling protocols, (ii) a centralized, SDN-like,
   control plane, and (iii) a hybrid control plane. 

   The Time-Sensitive Networking (TSN) Task Group (TG) is a part of the
   IEEE 802.1 Working Group (WG) (https://1.ieee802.org/tsn/). The
   charter of the TSN TSG is to provide deterministic services for time
   sensitive applications through IEEE 802 networks, i.e., guaranteed
   packet transport with bounded latency, low packet delay variation,
   and low packet loss.

   The TSN TG has developed basic data plane techniques for providing
   deterministic services within an IEEE 802.1Q network. Key aspects are
   to provide resource reservation for deterministic services by making
   use of a separate queue, access control, and determining the upper-,
   lower- and in-class interference on the egress side for bounded
   latency. This model for traffic from time sensitive applications,
   called TSN model, and the associated data plane techniques for time
   sensitive traffic can be applied to different lower layer network
   technologies and is not limited to IEEE 802.1Q bridges. DetNet uses
   for its DnFlows deterministic services provided by the lower layer
   network technologies. 

   While many deterministic IP deployments make use of pre-planned flow
   allocations, using an often centrally managed approach, this draft
   investigates the use of RSVP [RFC2205] for allowing endpoints to
   dynamically signal deterministic IP connectivity in combination with
   underlying Layer 2 mechanisms, specifically those used for TSN
   networks. When doing so, considerations arise for the development of
   a Layer2-specific RSVP protocol, called RSVP TSN in the following. 

   This document will outline use cases for RSVP TSN, followed by the
   design rationale and specification for the proposed RSVP TSN
   protocol.

   Note that the document does NOT cover aspects of traffic engineering,
   specifically for a more detnet-focused revision of RSVP-TE. However,
   the work in this draft is meant to provide more insights into the
   possible working of RSVP for detnet (here focused over a specific L2
   technology, namely TSN), which may in turn be used for a more general
   work on detnet-specific extensions needed for RSVP overall. As such,
   this document has been narrowed in scope from its previous version in
   [ID-trossen-detnet-control-signaling].

 


Trossen, et al.          Expires July 11, 2022                  [Page 3]

INTERNET DRAFT           RSVP for TSN Networks                          


   This document bases its work on the need for end-device initiated
   DetNet sessions, utilizing RSVP or some possible DetNet-specific
   modification for doing so. Examples for scenarios are, although not
   limited to, Industrial M2M (machine-to-machine) ones, as also
   documented in [RFC8578]. Efforts to document the motivation, problems
   and use cases for device-initiated DetNet flows will be initiated as
   a result of discussions surrounding this draft.

1.1.  Terminology

   This document uses the terminology established in the DetNet
   Architecture [RFC8655], and the reader is assumed to be familiar with
   that document and its 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].

2.  Use Cases

   A deterministic network [RFC8655] is composed of DetNet-enabled end
   systems and DetNet relay nodes which deliver deterministic services.
   As shown in Figure 1, TSN-enabled end systems can still make use of
   deterministic networking when they are connected to an DetNet edge
   node supporting service proxy function to establish a deterministic
   end-to-end service. 

   TSN               Edge        Transit         Relay      DetNet      
   End System        Node         Node           Node       End System  
   +----------+   +---------+                               +----------+
   |  Appl.   |<--:Svc Proxy:-------End-to-End Service----->|  Appl.   |
   +----------+   +---------+                 +---------+   +----------+
   |  TSN     |   |TSN| |Svc|<--DetNet flow---: Service :-->| Service  |
   +----------+   +-.-+ +-.-+   +---------+   +---------+   +----------+
   |Forwarding|   |Fwd| |Fwd|   |   Fwd   |   |Fwd| |Fwd|   |Forwarding|
   +-------.--+   +-.-+ +-.-+   +--.----.-+   +-.-+ +-.-+   +---.------+
           :        :    / ,-----.     :       :     / ,-----.        
           +........+   +-[  Sub- ]--+  +.......+    +-[  Sub- ]--+     
                          [network]                    [network]        
                           '-----'                      '-----'
                   Figure 1 : Deterministic Network with TSN-enabled End
   Systems

   In principle, three use cases are of interest for the establishment
   of deterministic end-to-end service over deterministic networks:
   (a) DetNet-enabled edge nodes with service proxy on both side because
       the connected source and destination are TSN-enabled end systems 

 


Trossen, et al.          Expires July 11, 2022                  [Page 4]

INTERNET DRAFT           RSVP for TSN Networks                          


   (b) Detnet enabled edge nodes with service proxy on one side because
       the connected source or destination are TSN-enabled end systems
       and on the other side the connected source or destination are
       Detnet-enabled end-systems

   (c) DetNet-enabled end systems are connected to a network supporting
       end-to-end deterministic services


   For the establishment of deterministic end-to-end connectivity based
   on DnFlows, an end-2-end signaling protocol called RSVP TSN for
   DnFlows is proposed. To achieve deterministic QoS, access control for
   a DnFlow is required because each DnFlow must be known by the network
   supporting DetNet. 

   The establishment of deterministic end-to-end connectivity is in
   principle comparable with the establishment of TCP connectivity. The
   main difference is that all network elements must take active part in
   the establishment of a deterministic end-to-end connectivity.  

   RSVP TSN is an option which can be used to signal DnFLow information
   between

   a) DetNet-enabled edge nodes,

   b) DetNet-enabled edge nodes and DetNet-enabled end system,

   c) DetNet-enabled end systems,

   d) DetNet-enabled end system and first DetNet-enabled relay node,

   e) and DetNet-enabled relay node


   NOTE: the next revision of the draft will include a more elaborate
   reasoning as to why a dynamic signaling may be desirable, possibly
   alongside managed approaches. 

   Several years ago, the IETF has introduced RSVP Intserv to exchange
   flow information for integrated services. Because deterministic
   service based on TSN differs from integrated services, additional
   RSVP object definitions are required for RSVP TSN.

   Goal of this contribution is to use RSVP TSN for signaling DnFlow
   information to dynamically establish deterministic end-to-end
   connectivity. DetNet-enabled end systems support RSVP TSN. There is
   no need for edge nodes with proxy services. DetNet-unware or TSN-
   aware end-systems presume edge nodes supporting proxy services when
 


Trossen, et al.          Expires July 11, 2022                  [Page 5]

INTERNET DRAFT           RSVP for TSN Networks                          


   they want have benefit from DetNet.

   In the detnet stack model [RFC 8938], "Resource allocation" is
   located in the forwarding sub-layer. In this document, the term
   "Signaling" is used instead of the term "Resource allocation". One
   reason for using the term "Signaling" is because the lower layer
   network technologies like IEEE 802.1Q with TSN enhancements are
   responsible to allocate queuing, bandwidth and latency resources to
   provide deterministic services.


3.  Design Rationale

   IntServ and TSN have defined different models providing deterministic
   QoS. This section will explore the design rationale behind the
   development of RSVP TSN. It also outlines aspects derived from the
   underlaying TSN capable lower layer network technology before
   highlighting key design considerations for the presentation of RSVP
   TSN in Section 4.

3.1.  RSVP IntServ vs RSVP TSN Data Plane Model

   The RSVP IntServ [RFC2212] model provides a flow bandwidth driven
   latency model with a separate transmission queue per flow. RSVP
   IntServ assumes a weighted fair queuing (WFQ) at the data plane,
   where a listener is able to influence therefore the latency through
   the reserved bandwidth per flow.

   RSVP TSN assumes deterministic services are provided by lower layer
   network technologies supporting the TSN model. The TSN model itself
   is in contrasts with the RSVP IntServ [RFC2212] model. Lower layer
   network technologies providing deterministic services for traffic
   from time sensitive applications make use of separate queues, access
   control, resource reservation and determine the upper-, lower- and
   in-class interference on the egress side for bounded latency

3.2.  RSVP IntServ vs RSVP TSN Resource Reservation Styles

   RSVP IntServ has introduced the notion of 'sessions' to maintain
   different kinds of deterministic end-to-end connectivity and resource
   styles, namely fixed (i) filter style, (ii) shared explicit style,
   and (iii) wildcard filter style - see [RFC2205]. The receiver
   controls sender selection and resource styles selection. The receiver
   is also able to influence latency for a flow by requesting certain
   amount of bandwidth.

   RSVP TSN splits the control over sender selection and resource
   styles, due to the given TSN data plane model. The resource style is
 


Trossen, et al.          Expires July 11, 2022                  [Page 6]

INTERNET DRAFT           RSVP for TSN Networks                          


   controlled by the sender and the sender selection is controlled by
   the receiver. The Receiver cannot influence bandwidth for a DnFlow. 

   The resource style 'coordinated share' is introduced in RSVP TSN to
   support a large amount of small DnFlows with small data usage.
   Multiple separate resource reservations on lower layer for small
   DnFlows could become very inefficient.

                    ||              Resource Style                    |
          Sender    ||             |             | NEW:               |
         Selection  ||  Distinct   |   Shared    | Coordinated Shared |
   -----------------||-------------|-------------|--------------------|
                    ||             |             |                    |
        Explicit    ||  supported  |  supported  |    supported       |
   -----------------||-------------|-------------|--------------------|
                    ||             |             |                    |
        Wildcard    ||             |  supported  |                    |
   -----------------||------------------------------------------------|
            Figure 2: Resource Style and Sender Selection [RFC2205]

3.3.  RSVP IntServ vs RSVP TSN Object Definitions

   Due to the differences described above, not all object definitions
   from RSVP IntServ can be applied to RSVP TSN. Also, not all features
   are supported in the same way as is done by RSVP IntServ since RSVP
   TSN assumes a deterministic service to be provided by the lower
   network layer.

   For instance, IEEE 802.1Q networks with TSN enhancements provides
   deterministic services by a layer 2 protocol for resource allocation
   for Sstreams [IEEE P802.1Qdd - Resource Allocation Protocol]. Such an
   allocated Sstream can transport one or multiple DnFlows. A StreamID
   is used for the identification at the layer 2 control plane. 

   To correlate DnFlow with their lower layer transport steams a stream
   identifier information must be distributed by RSVP TSN. This is only
   one of the reasons for introducing additional RSVP object
   definitions.

3.4 RSVP IntServ vs RSVP TSN Flow Specification

   In RSVP IntServ, the flow specification describes both the
   characteristics of the traffic sent by the source and the service
   requirements of the application. The flow specification of RSVP
   IntServ is token bucket based. The sender TSpec is a description of
   the allowed traffic characteristics for which service is being
   requested. Each receiver describes by RSpec the service it desires to
   receive. The RSpec is carried form the receiver to the intermediate
 


Trossen, et al.          Expires July 11, 2022                  [Page 7]

INTERNET DRAFT           RSVP for TSN Networks                          


   network elements and flows upstream towards the sender. It may be
   used or updated at the intermediate network elements before arriving
   the sender. The ADSpec object carries information which is generated
   at either data sources or intermediate network elements, is flowing
   downstream towards receivers.

   In RSVP TSN, the sender TSpec information is also a description of
   the allowed traffic characteristics for which service is being
   requested. The receiver cannot describe the service it desires to
   receive. The traffic specification itself can be token bucket based
   but also variants based on intervals are supported. RSVP TSN does not
   support RSpec. It is not able to support heterogeneous receivers
   where each makes reservation requests with different QoS requirements
   on per DnFlow session.

   These differences pose a number of questions:

   1. Is RSVP IntServ (as defined in [RFC2212]) the right starting point
      to deliver DnFlow information and trigger resource allocation on
      lower layer network technologies supporting the TSN model?

   2. How to efficiently map the different reservation styles of RSVP
      TSN (originally introduced by RSVP IntServ) onto the TSN data
      plane model?

   3. What is the nature of the interface between RSVP TSN and lower
      layer resource reservation?

   4. How does the binding between DnFlow signaling of RSVP TSN and
      lower layer resource reservation look like?

   5. Which of the different RSVP TSN traffic specifications shall be
      supported?

      Note: Different traffic specifications exist for an efficient
      mapping of traffic specification to scheduling model.

               |   Time based    | Token Bucket    | Priority based | 
               |   Scheduling    | based           | (none shaping  | 
               |                 | Scheduling      | network nodes) | 
      ---------+-----------------+-----------------+----------------+ 
      Stream/  | Proposal:       | Asynchronous    | Highest        | 
      Flow     | Dampers with    | Traffic Shaping | (static)       | 
      Based    | Forward Traffic | (ATS)           | priority       | 
               | isolation       | (IEEE 802.1Qcr) |                |
      ---------+-----------------+-----------------+----------------+ 
      Class    |Cyclic Queuing & |  Credit-Based   |                | 
      Based    |Forwarding (CQF) |  Shaper (CBSA)  |                | 
 


Trossen, et al.          Expires July 11, 2022                  [Page 8]

INTERNET DRAFT           RSVP for TSN Networks                          


               | (IEEE 802.1Qch) | (IEEE 802.1Qav) |                | 
      ---------------------------------------------------------------
               Figure 3: Comparison of TSN and RSVP-IntServ Models

   The proposal for dumper is discussed within the IEEE 802.1 TSN WG
   (see https://www.ieee802.org/1/files/public/docs2020/new-specht-
   dampers-fti-0620-v02.pdf).

   For instance, the Resource-Allocation-Protocol (RAP) [RAP_IEEE]
   introduces templates to describe traffic class for streams with its
   scheduling model and the associated traffic specification for
   streams.

4.  RSVP TSN

   This section specifies the APIs for RSVP TSN, the message formats,
   and outlines the layer and node interactions in an RSVP TSN based
   system.

4.1.  Layer Interactions between RSVP TSN and Lower Layer Resource
   Allocation

   Figure 4 provides an overview of the interactions between lower layer
   resource allocation and DnFlow signaling in a network deployment as
   an elaboration of the elements in Figure 1, also illustrating the
   various interfaces described in the following sections.

   The application utilizes a generalized API for deterministic QoS
   (dQoS), which controls and signals the establishment DnFlow via the
   upper API of RSVP TSN. The latter is called DnFlow-Signaling-
   Interface(uRSVPDnFSI) in this contribution.

   DetNet end nodes utilize RSVP TSN to distribute DnFlow information by
   end-to end signaling over DetNet Route. 

   The lower API of RSVP TSN is called DnFlow-Transport-Interface
   (DnFTI) in this contribution. The DnFTI has connectivity with the
   lower network layer, which in turn provides deterministic services
   within a subnetwork based on the TSN model. 

   For instance, IEEE 802.1Q with extensions for TSN establish streams
   to transport DnFlows.  For stream reservation the Resource-
   Allocation-Protocol (RAP) [RAP_IEEE]  has defined the Reservation-
   Service-Interface (RSI).

   The following figure illustrates the information flow within a DetNet
   end system and a DetNet relay node for the establishment of
   deterministic end-2-end services.
 


Trossen, et al.          Expires July 11, 2022                  [Page 9]

INTERNET DRAFT           RSVP for TSN Networks                          


       DetNet                                            DetNet         
     End System                                        Relay Node     
   +------------+ 
   |Time        |
   |Sensitive   |
   |Application | 
   +------------+ 
     | dQoS  |    
     |       |    
     |C     S|    
     |       |    
     | DnFSI |    
   +------------+                                    +-------------+ 
   |  RSVP TSN  |<---------------------------------->|  RSVP TSN   | 
   +------------+                                    +-------------+ 
     | DnFTI |                                        |   |   |   |  
     |       |                                        |   |   |   |  
     |M&A   S|                                        |M S|   |M S|  
     |       |                                        |   |   |   |  
   +-------------+     +-----------------------+     +-------------+ 
   | Lower Layer |<===>|        Lower Layer    |<===>| Lower Layer | 
   |  TSN aware  |     | TSN aware  Subnetwork |     |  TSN aware  | 
   +-------------+     +-----------------------+     +-----+ +-----+ 


   <--->   DnFlow Signaling Service                                     
   <===>   Lower layer transport stream/flow reservation service        
   <===>   TSN Stream Reservation
   dQoS    Deterministic QoS time sensitive application interface       
   DnFSI   DnFlow-Service-Interface (upper API of RSVP TSN)
   DnFTI   DnFlow-Transport-Interface(lower API of RSVP TSN)
   C       Control        
   S       Signaling      
   M&A     Maps and Aggregation           

            Figure 4: Layer Interactions between RSVP TSN and lower
   layer network supporting TSN

4.2.  API for Deterministic QoS (dQoS)

   The description of a generalized API to support deterministic QoS is
   not part of this document.

4.3.  DnFlow Signaling Interface (DnFSI)

   The definition of the DnFSI and the DnFTI is based on the DnFlow
   information model [ID-detnet-flow-information-model].

 


Trossen, et al.          Expires July 11, 2022                 [Page 10]

INTERNET DRAFT           RSVP for TSN Networks                          


   This interface is oriented on the interface specified by RSVP-IntServ
   (RFC 2205). Most of the changes are due to mapping resource
   reservation styles (see Section 3.2).

     Sender

     Call: Open Session (oriented to the RSVP-IntServ interface)

       Request parameter (make use of pieces from the
       DnFlowSpecification)

       - DestinationIpAddress, Protocol, DestinationPort

       Response parameter:

       - SessionID

     Call: Add DnFlow 

        Request parameter (make use of pieces from the
       DnFlowSpecification)

        - SessionID, SourceIpAddress, SourcePort, DSCP

       -  DnTrafficSpecification: Interval, MaxPacketsPerInterval,
       MaxPayloadSize, MinPayloadSize

       - DnFLowRank

       - Select one of the Resource Style: Distinct, Shared,
       CoordinatedShared

       - Data TTL, PATH MTU size, LossRate

     Notes for new parameter: 

     The DSCP is required to map DnFlows according their service class
     to offered service classes of the lower layer.

     The resource style for an DnFlow is announced by the sender within
     the path message.

     The LossRate is accumulated per DnFlow from Sender to Receiver.

     Upcall: DnFlow

       - Session ID

 


Trossen, et al.          Expires July 11, 2022                 [Page 11]

INTERNET DRAFT           RSVP for TSN Networks                          


       - One of the Info_type: RESV_EVENT; PATH_ERROR

     Receiver

     Call: Open Session 

       Request parameter (make use of pieces from the
       DnFlowSpecification)

       - DestinationIpAddress, Protocol, DestinationPort

       Response parameter

       - SessionID

     Call: Join DnFlow

       Request parameter

       - SessionID

       - Select one of the DnFlow Source Selection: Wildcard, List of
       explicit sources with SourcePort

       - MaximumPacketSize

       - Extended Traffic Specification: MaximumExpectedLatency

     Notes for new parameter:

     The Source Selection is split from the RSVP-IntServ Reservation
     Style but still follows the rules defined by RSVP-IntServ.

     The extended traffic specification MaximumExpectedLatency is
     propagated and merged to a minimum upstream from receiver to
     sender.

     Upcall: DnFlow

       - SessionID

       - SourceIpAddress (Sender) 

       - SourcePort

       - One of the Info_type: RESV_EVENT; PATH_ERROR

     General 
 


Trossen, et al.          Expires July 11, 2022                 [Page 12]

INTERNET DRAFT           RSVP for TSN Networks                          


     Call: Close Session

       Request parameter

       - SessionID

4.4.  DnFlow Transport Interface (DnFTI)


     Sender

     Call: Add DnFlow

       Request parameter

       - SessionID, Interface, DnFlowID, DestinationIpAddress, DSCP

       - DnTrafficSpecification: Interval, MaxPacketsPerInterval,
       MaxPayloadSize, MinPayloadSize, MinPacketsInterval

       - One of the Resource Styles: Distinct, Shared, Coordinated
       Shared

       Response parameter

       - TransportFlowID (TSN StreamID)

     Notes for new parameter:

     The DnFlowID is a local parameter  to correlate DnFlows to
     transport flows (e.g., TSN Stream).

     The TransportFlowID correlates the DnFlow to the lower layer
     transport flow, e.g., TSN Stream ID.

     Upcall: DnFlow

       Response parameter

       - SessionID

       - TransportFlowID

       - One of the Info_type: RESV_EVENT, RES_MODIFY_EVENT

     Receiver

     Call: Join DnFlow
 


Trossen, et al.          Expires July 11, 2022                 [Page 13]

INTERNET DRAFT           RSVP for TSN Networks                          


       Request parameter

       - SessionID, Interface, DnFlowID, TransportFlowID

       - MaximumPacketSize

       - Extended Traffic Specification: MaximumExpectedLatency

     Notes for new parameter:

     (see notes above)

     Upcall: DnFlow

       Response parameter

       - SessionID, TransportFlowID

       - One of the Info_type: ANNOUNCE_EVENT, ANNOUNCE_MODIFY_EVENT

4.5.  RSVP TSN Message Formats

   TBD

5.  Security Considerations

   Editor's note: This section needs more details.

6.  IANA Considerations

   N/A

7.  Conclusion

   This draft outlines recommended changes to RSVP signaling in the form
   of RSVP TSN for a better alignment of the Layer 3 signaling with that
   of emerging Layer 2 solutions, together with suggested API
   specifications for the realization of the L3 to L2 interfaces in
   endpoints.

8.  References

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


Trossen, et al.          Expires July 11, 2022                 [Page 14]

INTERNET DRAFT           RSVP for TSN Networks                          


   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655, DOI
              10.17487/RFC8655, October 2019, <https://www.rfc-
              editor.org/info/rfc8655>.

   [RFC2212]  Shenker, S., Partridge, C., and Guerin, R., "Specification
              of Guaranteed Quality of Service", RFC 2212, September
              1997.

   [RFC2205]  R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jasmin, "
              Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC8578] E. Grossman (ed.), "Deterministic Networking Use Cases",
              RFC8578, May 2019

   [RFC8655] N. Finn, B. Thubert, B. Vargas, J. Farkas, "Deterministic
              Networking Architecture", RFC8655, October 2019

   [RFC8938]  B. Varga, Ed, J. Farkas, L. Berger, A. Malis, S. Bryant,
              "Deterministic Networking (DetNet) Data Plane Framework",
              RFC8938, November 2020. 

8.2.  Informative References

   [ID.malis-detnet-controller-plane-framework] A. Malis, X. Geng, M.
              Chen, F. Qin, B. Varga, "Deterministic Networking (DetNet)
              Controller Plane Framework", draft-malis-detnet-
              controller-plane-framework-05 (work in progress), 2020

   [ID-detnet-flow-information-model] Balazs Varga, Janos Farkas, Rodney
              Cummings, Yuanlong Jiang, Don Fedyk, "DetNet Flow and
              Service Information Model", draft-ietf-detnet-flow-
              information-model-14 (work in progress), 2021

   [CHEN-IEEE] F. Chen, F.J. Goetz, M. Kiessling, J. Schmitt, " Support
              for uStream Aggregation in RAP (ver 0.3)" (work in
              progess), Jan 2019,
              <http://www.ieee802.org/1/files/public/docs2019/dd-chen-
              flow-aggregation-0119-v03.pdf>

   [RAP_IEEE] IEEE, "P802.1Qdd - Resource Allocation Protocol", (work in
              progress), <https://1.ieee802.org/tsn/802-1qdd/>

   [ID-trossen-detnet-control-signaling] D. Trossen, F.-J. Goetz, J.
              Schmitt, "DetNet Control Plane Signaling", draft-trossen-
              detnet-control-signaling-01 (work in progress), 2021

 


Trossen, et al.          Expires July 11, 2022                 [Page 15]

INTERNET DRAFT           RSVP for TSN Networks                          


   Authors' Addresses

   Dirk Trossen
   Huawei Technologies Duesseldorf GmbH
   Riesstr. 25C
   80992 Munich
   Germany		

   Email: Dirk.Trossen@Huawei.com



   Franz-Josef Goetz
   Siemens AG
   Gleiwitzer-Str. 555
   90475 Nuremberg
   Germany

   Email: franz-josef.goetz@siemens.com 



   Juergen Schmitt
   Siemens AG
   Gleiwitzer Str. 555
   90475 Nuremberg
   Germany

   Email: juergen.jues.schmitt@siemens.com 






















Trossen, et al.          Expires July 11, 2022                 [Page 16]