| rfc9024.original | rfc9024.txt | |||
|---|---|---|---|---|
| DetNet B. Varga, Ed. | Internet Engineering Task Force (IETF) B. Varga, Ed. | |||
| Internet-Draft J. Farkas | Request for Comments: 9024 J. Farkas | |||
| Intended status: Standards Track Ericsson | Category: Standards Track Ericsson | |||
| Expires: August 23, 2021 A. Malis | ISSN: 2070-1721 A. Malis | |||
| Malis Consulting | Malis Consulting | |||
| S. Bryant | S. Bryant | |||
| Futurewei Technologies | Futurewei Technologies | |||
| D. Fedyk | D. Fedyk | |||
| LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
| February 19, 2021 | June 2021 | |||
| DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS | Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive | |||
| draft-ietf-detnet-tsn-vpn-over-mpls-07 | Networking over MPLS | |||
| Abstract | Abstract | |||
| This document specifies the Deterministic Networking data plane when | This document specifies the Deterministic Networking data plane when | |||
| TSN networks are interconnected over a DetNet MPLS Network. | Time-Sensitive Networking (TSN) networks are interconnected over a | |||
| DetNet MPLS network. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
| 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 | This document is a product of the Internet Engineering Task Force | |||
| and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
| time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
| material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | ||||
| This Internet-Draft will expire on August 23, 2021. | Information about the current status of this document, any errata, | |||
| and how to provide feedback on it may be obtained at | ||||
| https://www.rfc-editor.org/info/rfc9024. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology | |||
| 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 | 2.1. Terms Used in This Document | |||
| 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Abbreviations | |||
| 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 2.3. Requirements Language | |||
| 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4 | 3. IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario | |||
| 4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6 | 4. DetNet MPLS Data Plane | |||
| 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Overview | |||
| 4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7 | 4.2. TSN over DetNet MPLS Encapsulation | |||
| 5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8 | 5. TSN over MPLS Data Plane Procedures | |||
| 5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8 | 5.1. Edge Node TSN Procedures | |||
| 5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9 | 5.2. Edge Node DetNet Service Proxy Procedures | |||
| 5.3. Edge Node DetNet Service and Forwarding Sub-Layer | 5.3. Edge Node DetNet Service and Forwarding Sub-Layer | |||
| Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 | Procedures | |||
| 6. Controller Plane (Management and Control) Considerations . . 11 | 6. Controller Plane (Management and Control) Considerations | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 8. IANA Considerations | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | 9. References | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 9.1. Normative References | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 | 9.2. Informative References | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 14 | Acknowledgements | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | Authors' Addresses | |||
| 1. Introduction | 1. Introduction | |||
| The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1 | The Time-Sensitive Networking Task Group (TSN TG) within the IEEE | |||
| Working Group deals with deterministic services through IEEE 802 | 802.1 Working Group deals with deterministic services through IEEE | |||
| networks. Deterministic Networking (DetNet) defined by IETF is a | 802 networks. Deterministic Networking (DetNet) defined by the IETF | |||
| service that can be offered by a L3 network to DetNet flows. General | is a service that can be offered by an L3 network to DetNet flows. | |||
| background and concepts of DetNet can be found in [RFC8655]. | General background and concepts of DetNet can be found in [RFC8655]. | |||
| This document specifies the use of a DetNet MPLS network to | This document specifies the use of a DetNet MPLS network to | |||
| interconnect TSN nodes/network segments. DetNet MPLS data plane is | interconnect TSN nodes/network segments. The DetNet MPLS data plane | |||
| defined in [RFC8964]. | is defined in [RFC8964]. | |||
| 2. Terminology | 2. Terminology | |||
| 2.1. Terms Used in This Document | 2.1. Terms Used in This Document | |||
| This document uses the terminology and concepts established in the | This document uses the terminology and concepts established in the | |||
| DetNet architecture [RFC8655] and [RFC8938], and [RFC8964]. TSN | DetNet architecture [RFC8655] [RFC8938] [RFC8964]. TSN-specific | |||
| specific terms are defined in the TSN TG of IEEE 802.1 Working Group. | terms are defined in the TSN TG of the IEEE 802.1 Working Group. The | |||
| The reader is assumed to be familiar with these documents and their | reader is assumed to be familiar with these documents and their | |||
| terminology. | terminology. | |||
| 2.2. Abbreviations | 2.2. Abbreviations | |||
| The following abbreviations are used in this document: | The following abbreviations are used in this document: | |||
| AC Attachment Circuit. | AC Attachment Circuit | |||
| CE Customer Edge equipment. | CE Customer Edge equipment | |||
| d-CW DetNet Control Word. | d-CW DetNet Control Word | |||
| DetNet Deterministic Networking. | DetNet Deterministic Networking | |||
| DF DetNet Flow. | DF DetNet Flow | |||
| FRER Frame Replication and Elimination for Redundancy (TSN | FRER Frame Replication and Elimination for Redundancy (TSN | |||
| function). | function) | |||
| L2 Layer 2. | L2 Layer 2 | |||
| L2VPN Layer 2 Virtual Private Network. | L2VPN Layer 2 Virtual Private Network | |||
| L3 Layer 3. | L3 Layer 3 | |||
| LSR Label Switching Router. | LSP Label Switched Path | |||
| MPLS Multiprotocol Label Switching. | LSR Label Switching Router | |||
| MPLS-TE Multiprotocol Label Switching - Traffic Engineering. | MPLS Multiprotocol Label Switching | |||
| NSP Native Service Processing. | MPLS-TE Multiprotocol Label Switching - Traffic Engineering | |||
| OAM Operations, Administration, and Maintenance. | NSP Native Service Processing | |||
| PE Provider Edge. | OAM Operations, Administration, and Maintenance | |||
| PREOF Packet Replication, Elimination and Ordering Functions. | PE Provider Edge | |||
| PW PseudoWire. | PREOF Packet Replication, Elimination and Ordering Functions | |||
| S-PE Switching Provider Edge. | PW Pseudowire | |||
| T-PE Terminating Provider Edge. | S-PE Switching Provider Edge | |||
| TSN Time-Sensitive Network. | T-PE Terminating Provider Edge | |||
| TSN Time-Sensitive Network | ||||
| 2.3. Requirements Language | 2.3. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario | 3. IEEE 802.1 TSN over DetNet MPLS Data Plane Scenario | |||
| Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware | Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN-aware | |||
| DetNet service running over an MPLS network. DetNet Edge Nodes sit | DetNet service running over an MPLS network. DetNet edge nodes sit | |||
| at the boundary of a DetNet domain. They are responsible for mapping | at the boundary of a DetNet domain. They are responsible for mapping | |||
| non-DetNet aware L2 traffic to DetNet services. They also support | non-DetNet-aware L2 traffic to DetNet services. They also support | |||
| the imposition and disposition of the required DetNet encapsulation. | the imposition and disposition of the required DetNet encapsulation. | |||
| These are functionally similar to pseudowire (PW) Terminating | These are functionally similar to PW T-PE nodes, which use MPLS-TE | |||
| Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example | LSPs. In this example, TSN Streams are simple applications over | |||
| TSN Streams are simple applications over DetNet flows. The specific | DetNet flows. The specifics of this operation are discussed later in | |||
| of this operation are discussed later in this document. | this document. | |||
| TSN Edge Transit Edge TSN | TSN Edge Transit Edge TSN | |||
| End System Node Node Node End System | End System Node Node Node End System | |||
| (T-PE) (LSR) (T-PE) | (T-PE) (LSR) (T-PE) | |||
| +----------+ +----------+ | +----------+ +----------+ | |||
| | TSN | <---------End to End TSN Service----------> | TSN | | | TSN | <-------- End-to-End TSN Service ---------> | TSN | | |||
| | Applic. | | Applic. | | | Applic. | | Applic. | | |||
| +----------+ +.........+ +.........+ +----------+ | +----------+ +.........+ +.........+ +----------+ | |||
| | | | \S-Proxy: :S-Proxy/ | | | | | | | \S-Proxy: :S-Proxy/ | | | | |||
| | TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN | | | TSN | | +.+---+<-- DetNet flow -->+---+ | | | TSN | | |||
| | | |TSN| |Svc| |Svc| |TSN| | | | | | |TSN| |Svc| |Svc| |TSN| | | | |||
| +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+ | +----------+ +---+ +---+ +----------+ +---+ +---+ +----------+ | |||
| | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 | | | L2 | | L2| |Fwd| |Forwarding| |Fwd| |L2 | | L2 | | |||
| +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+ | +------.---+ +-.-+ +-.-+ +---.----.-+ +--.+ +-.-+ +---.------+ | |||
| : Link : / ,-----. \ : Link : / ,-----. \ | : Link : / ,-----. \ : Link : / ,-----. \ | |||
| +........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+ | +........+ +-[ Sub ]-+ +........+ +-[ TSN ]-+ | |||
| [Network] [Network] | [Network] [Network] | |||
| `-----' `-----' | `-----' `-----' | |||
| |<------ DetNet MPLS ------>| | |<------ DetNet MPLS ------>| | |||
| |<---------------------- TSN --------------------->| | |<---------------------- TSN --------------------->| | |||
| Figure 1: A TSN over DetNet MPLS Enabled Network | Figure 1: A TSN over DetNet MPLS-Enabled Network | |||
| In this example, edge nodes provide a service proxy function that | In this example, edge nodes provide a service proxy function that | |||
| "associates" the DetNet flows and native flows (i.e., TSN Streams) at | "associates" the DetNet flows and native flows (i.e., TSN Streams) at | |||
| the edge of the DetNet domain. TSN streams are treated as App-flows | the edge of the DetNet domain. TSN Streams are treated as App-flows | |||
| for DetNet. The whole DetNet domain behaves as a TSN relay node for | for DetNet. The whole DetNet domain behaves as a TSN relay node for | |||
| the TSN streams. The service proxy behaves as a port of that TSN | the TSN Streams. The service proxy behaves as a port of that TSN | |||
| relay node. | relay node. | |||
| Figure 2 illustrates how DetNet can provide services for IEEE 802.1 | Figure 2 illustrates how DetNet can provide services for IEEE 802.1 | |||
| TSN end systems, CE1 and CE2, over a DetNet enabled MPLS network. | TSN end systems, CE1 and CE2, over a DetNet-enabled MPLS network. | |||
| Edge nodes, E1 and E2, insert and remove required DetNet data plane | Edge nodes E1 and E2 insert and remove the required DetNet data plane | |||
| encapsulation. The 'X' in the edge nodes and relay node, R1, | encapsulation. The 'X' in the edge nodes and relay node, R1, | |||
| represent a potential DetNet compound flow packet replication and | represent a potential DetNet compound flow packet replication and | |||
| elimination point. This conceptually parallels L2VPN services, and | elimination point. This conceptually parallels L2VPN services and | |||
| could leverage existing related solutions as discussed below. | could leverage existing related solutions as discussed below. | |||
| TSN |<------- End to End DetNet Service ------>| TSN | TSN |<------- End-to-End DetNet Service ------>| TSN | |||
| Service | Transit Transit | Service | Service | Transit Transit | Service | |||
| TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN | TSN (AC) | |<-Tnl->| |<-Tnl->| | (AC) TSN | |||
| End | V V 1 V V 2 V V | End | End | V V 1 V V 2 V V | End | |||
| System | +--------+ +--------+ +--------+ | System | System | +--------+ +--------+ +--------+ | System | |||
| +---+ | | E1 |=======| R1 |=======| E2 | | +---+ | +---+ | | E1 |=======| R1 |=======| E2 | | +---+ | |||
| | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| | | | |--|----|._X_....|..DF1..|.._ _...|..DF3..|...._X_.|---|---| | | |||
| |CE1| | | \ | | X | | / | | |CE2| | |CE1| | | \ | | X | | / | | |CE2| | |||
| | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | | | | | | \_.|..DF2..|._/ \_..|..DF4..|._/ | | | | |||
| +---+ | |=======| |=======| | +---+ | +---+ | |=======| |=======| | +---+ | |||
| ^ +--------+ +--------+ +--------+ ^ | ^ +--------+ +--------+ +--------+ ^ | |||
| | Edge Node Relay Node Edge Node | | | Edge Node Relay Node Edge Node | | |||
| | (T-PE) (S-PE) (T-PE) | | | (T-PE) (S-PE) (T-PE) | | |||
| | | | | | | |||
| |<- TSN -> <------- TSN Over DetNet MPLS -------> <- TSN ->| | |<- TSN -> <------- TSN over DetNet MPLS -------> <- TSN ->| | |||
| | | | | | | |||
| |<-------- Time Sensitive Networking (TSN) Service ------->| | |<-------- Time-Sensitive Networking (TSN) Service ------->| | |||
| X = Service protection | X = Service protection | |||
| DFx = DetNet member flow x over a TE LSP | DFx = DetNet member flow x over a TE LSP | |||
| AC = Attachment Circuit | AC = Attachment Circuit | |||
| Tnl = Tunnel | Tnl = Tunnel | |||
| Figure 2: IEEE 802.1TSN Over DetNet | Figure 2: IEEE 802.1TSN over DetNet | |||
| 4. DetNet MPLS Data Plane | 4. DetNet MPLS Data Plane | |||
| 4.1. Overview | 4.1. Overview | |||
| The basic approach defined in [RFC8964] supports the DetNet service | The basic approach defined in [RFC8964] supports the DetNet service | |||
| sub-layer based on existing pseudowire (PW) encapsulations and | sub-layer based on existing PW encapsulations and mechanisms and | |||
| mechanisms, and supports the DetNet forwarding sub-layer based on | supports the DetNet forwarding sub-layer based on existing MPLS | |||
| existing MPLS Traffic Engineering encapsulations and mechanisms. | Traffic Engineering encapsulations and mechanisms. | |||
| A node operating on a DetNet flow in the Detnet service sub-layer, | A node operating on a DetNet flow in the DetNet service sub-layer, | |||
| i.e. a node processing a DetNet packet which has the S-Label as top | i.e., a node processing a DetNet packet that has the S-Label as top | |||
| of stack uses the local context associated with that S-Label, for | of stack, uses the local context associated with that S-Label. For | |||
| example a received F-Label, to determine what local DetNet | example, a received F-Label can be used to determine what local | |||
| operation(s) are applied to that packet. An S-Label may be unique | DetNet operation(s) is applied to that packet. An S-Label may be | |||
| when taken from the platform label space [RFC3031], which would | unique when taken from the platform label space [RFC3031], which | |||
| enable correct DetNet flow identification regardless of which input | would enable correct DetNet flow identification regardless of which | |||
| interface or LSP the packet arrives on. The service sub-layer | input interface or LSP the packet arrives on. The service sub-layer | |||
| functions (i.e., PREOF) use a DetNet control word (d-CW). | functions (i.e., PREOF) use a DetNet control word (d-CW). | |||
| The DetNet MPLS data plane builds on MPLS Traffic Engineering | The DetNet MPLS data plane builds on MPLS Traffic Engineering | |||
| encapsulations and mechanisms to provide a forwarding sub-layer that | encapsulations and mechanisms to provide a forwarding sub-layer that | |||
| is responsible for providing resource allocation and explicit routes. | is responsible for providing resource allocation and explicit routes. | |||
| The forwarding sub-layer is supported by one or more forwarding | The forwarding sub-layer is supported by one or more forwarding | |||
| labels (F-Labels). | labels (F-Labels). | |||
| DetNet edge/relay nodes are DetNet service sub-layer aware, | DetNet edge/relay nodes are DetNet service sub-layer aware, | |||
| understand the particular needs of DetNet flows and provide both | understand the particular needs of DetNet flows, and provide both | |||
| DetNet service and forwarding sub-layer functions. They add, remove | DetNet service and forwarding sub-layer functions. They add, remove, | |||
| and process d-CWs, S-Labels and F-labels as needed. MPLS DetNet | and process d-CWs, S-Labels, and F-Labels as needed. MPLS DetNet | |||
| nodes and transit nodes include DetNet forwarding sub-layer | nodes and transit nodes include DetNet forwarding sub-layer functions | |||
| functions, notably, support for explicit routes and resource | -- notably, support for explicit routes and resource allocation to | |||
| allocation to eliminate (or reduce) congestion loss and jitter. | eliminate (or reduce) congestion loss and jitter. Unlike other | |||
| Unlike other DetNet node types, transit nodes provide no service sub- | DetNet node types, transit nodes provide no service sub-layer | |||
| layer processing. | processing. | |||
| 4.2. TSN over DetNet MPLS Encapsulation | 4.2. TSN over DetNet MPLS Encapsulation | |||
| The basic encapsulation approach is to treat a TSN Stream as an App- | The basic encapsulation approach is to treat a TSN Stream as an App- | |||
| flow from the DetNet MPLS perspective. The corresponding example | flow from the DetNet MPLS perspective. The corresponding example is | |||
| shown in Figure 3. Note, that three example flows are shown in the | shown in Figure 3. Note that three example flows are shown in the | |||
| figure. | figure. | |||
| /-> +------+ +------+ +------+ TSN ^ ^ | /-> +------+ +------+ +------+ TSN ^ ^ | |||
| MPLS | | X | | X | | X |<- Appli : : | MPLS | | X | | X | | X |<- Appli : : | |||
| App-Flow <-+ +------+ +------+ +------+ cation : :(1) | App-Flow <-+ +------+ +------+ +------+ cation : :(1) | |||
| | |TSN-L2| |TSN-L2| |TSN-L2| : v | | |TSN-L2| |TSN-L2| |TSN-L2| : v | |||
| \-> +---+======+--+======+--+======+-----+ : | \-> +---+======+--+======+--+======+-----+ : | |||
| | d-CW | | d-CW | | d-CW | : | | d-CW | | d-CW | | d-CW | : | |||
| DetNet-MPLS +------+ +------+ +------+ :(2) | DetNet-MPLS +------+ +------+ +------+ :(2) | |||
| |Labels| |Labels| |Labels| v | |Labels| |Labels| |Labels| v | |||
| skipping to change at page 8, line 5 ¶ | skipping to change at line 297 ¶ | |||
| (2) DetNet MPLS Flow | (2) DetNet MPLS Flow | |||
| Figure 3: Examples of TSN over MPLS Encapsulation Formats | Figure 3: Examples of TSN over MPLS Encapsulation Formats | |||
| In the figure, "Application" indicates the application payload | In the figure, "Application" indicates the application payload | |||
| carried by the TSN network. "MPLS App-Flow" indicates that the TSN | carried by the TSN network. "MPLS App-Flow" indicates that the TSN | |||
| Stream is the payload from the perspective of the DetNet MPLS data | Stream is the payload from the perspective of the DetNet MPLS data | |||
| plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate | plane defined in [RFC8964]. A single DetNet MPLS flow can aggregate | |||
| multiple TSN Streams. | multiple TSN Streams. | |||
| Note: In order to avoid fragmentation (see section 5.3 of [RFC3985]), | | Note: Network fragmentation for DetNet is not supported and | |||
| the network operator has to make sure that all the DetNet | | MUST be avoided. The reason for this is that network | |||
| encapsulation overhead plus the TSN App-flow do not exceed the DetNet | | fragmentation is not consistent with the packet delivery times | |||
| network's MTU. | | needed for DetNet. Therefore, when IP is used as the sub- | |||
| | network, IPv6 fragmentation MUST NOT be used, and IPv4 packets | ||||
| | MUST be sent with the DF bit set. This means that the network | ||||
| | operator MUST ensure that all the DetNet encapsulation overhead | ||||
| | plus the maximum TSN App-flow frame size does not exceed the | ||||
| | DetNet network's MTU. | ||||
| 5. TSN over MPLS Data Plane Procedures | 5. TSN over MPLS Data Plane Procedures | |||
| The description of Edge Nodes procedures and functions for TSN over | The description of edge node procedures and functions for TSN over | |||
| DetNet MPLS scenarios follows the concepts from [RFC3985], and covers | DetNet MPLS scenarios follows the concepts from [RFC3985] and covers | |||
| the Edge Nodes components shown in Figure 1. In this section the | the edge node components shown in Figure 1. In this section, the | |||
| following procedures of DetNet Edge Nodes are described: | following procedures of DetNet edge nodes are described: | |||
| o TSN related (Section 5.1) | * TSN related (Section 5.1) | |||
| o DetNet Service Proxy (Section 5.2) | * DetNet Service Proxy (Section 5.2) | |||
| o DetNet service and forwarding sub-layer (Section 5.3) | * DetNet service and forwarding sub-layer (Section 5.3) | |||
| The sub-sections describe procedures for forwarding packets by DetNet | The subsections describe procedures for forwarding packets by DetNet | |||
| Edge nodes, where such packets are received from either directly | edge nodes, where such packets are received from either directly | |||
| connected CEs (TSN nodes) or some other DetNet Edge nodes. | connected CEs (TSN nodes) or some other DetNet edge nodes. | |||
| 5.1. Edge Node TSN Procedures | 5.1. Edge Node TSN Procedures | |||
| The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1 | The TSN TG of the IEEE 802.1 Working Group has defined (and is | |||
| Working Group have defined (and are defining) a number of amendments | defining) a number of amendments to [IEEE8021Q] that provide zero | |||
| to [IEEE8021Q] that provide zero congestion loss and bounded latency | congestion loss and bounded latency in bridged networks. | |||
| in bridged networks. [IEEE8021CB] defines packet replication and | [IEEE8021CB] defines packet replication and elimination functions for | |||
| elimination functions for a TSN network. | a TSN network. | |||
| The implementation of TSN entity (i.e., TSN packet processing | The implementation of a TSN entity (i.e., TSN packet processing | |||
| functions) must be compliant with the relevant IEEE 802.1 standards. | functions) must be compliant with the relevant IEEE 802.1 standards. | |||
| TSN specific functions are executed on the data received by the | TSN-specific functions are executed on the data received by the | |||
| DetNet Edge Node from the connected CE before being forwarded to | DetNet edge node from the connected CE before being forwarded to | |||
| connected CE(s) or presented to the DetNet Service Proxy function for | connected CE(s) or presented to the DetNet service proxy function for | |||
| transmission across the DetNet domain. TSN specific functions are | transmission across the DetNet domain. TSN-specific functions are | |||
| also executed on the data received from a DetNet PW by a PE before | also executed on the data received from a DetNet PW by a PE before | |||
| the data is output on the Attachment Circuit(s) (AC). | the data is output on the AC(s). | |||
| TSN packet processing function(s) of Edge Nodes (T-PE) are belonging | The TSN packet processing function(s) of edge nodes (T-PE) belongs to | |||
| to the native service processing (NSP) [RFC3985] block. This is | the NSP [RFC3985] block. This is similar to other functionalities | |||
| similar to other functionalities being defined by standard bodies | being defined by standards bodies other than the IETF (for example, | |||
| other than the IETF (for example in case of Ethernet: stripping, | in the case of Ethernet, stripping, overwriting, or adding VLAN tags, | |||
| overwriting or adding VLAN tags, etc.). Depending on the TSN role of | etc.). Depending on the TSN role of the edge node in the end-to-end | |||
| the Edge Node in the end-to-end TSN service selected TSN functions | TSN service, selected TSN functions are supported. | |||
| are supported. | ||||
| When a PE receives a packet from a CE, on a given AC with DetNet | When a PE receives a packet from a CE on a given AC with DetNet | |||
| service, it first checks via Stream Identification (see Clause 6. of | service, it first checks via Stream identification (see Clause 6 of | |||
| [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a | [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a | |||
| configured TSN Stream (i.e., App-flow from DetNet perspective). If | configured TSN Stream (i.e., App-flow from the DetNet perspective). | |||
| no Stream ID is matched and no other (VPN) service is configured for | If no Stream ID is matched and no other (VPN) service is configured | |||
| the AC, then the packet MUST be dropped. If there is a matching TSN | for the AC, then the packet MUST be dropped. If there is a matching | |||
| Stream, then the Stream ID specific TSN functions are executed (e.g., | TSN Stream, then the Stream-ID-specific TSN functions are executed | |||
| ingress policing, header field manipulation in case of active Stream | (e.g., ingress policing, header field manipulation in the case of | |||
| Identification, FRER, etc.). Source MAC lookup may also be used for | active Stream identification, FRER, etc.). Source Media Access | |||
| local MAC address learning. | Control (MAC) lookup may also be used for local MAC address learning. | |||
| If the PE decides to forward the packet, the packet MUST be forwarded | If the PE decides to forward the packet, the packet MUST be forwarded | |||
| according to the TSN Stream specific configuration to connected CE(s) | according to the TSN-Stream-specific configuration to connected CE(s) | |||
| (in case of local bridging) and/or to the DetNet Service Proxy (in | (in case of local bridging) and/or to the DetNet service proxy (in | |||
| case of forwarding to remote CE(s)). If there are no TSN Stream | case of forwarding to remote CE(s)). If there are no TSN-Stream- | |||
| specific forwarding configurations, the PE MUST flood the packet to | specific forwarding configurations, the PE MUST flood the packet to | |||
| other locally attached CE(s) and to the DetNet Service Proxy. If the | other locally attached CE(s) and to the DetNet service proxy. If the | |||
| administrative policy on the PE does not allow flooding, the PE MUST | administrative policy on the PE does not allow flooding, the PE MUST | |||
| drop the packet. | drop the packet. | |||
| When a TSN entity of the PE receives a packet from the DetNet Service | When a TSN entity of the PE receives a packet from the DetNet service | |||
| Proxy, it first checks via Stream Identification (see Clause 6. of | proxy, it first checks via Stream identification (see Clause 6 of | |||
| [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a | [IEEE8021CB] and [IEEEP8021CBdb]) whether the packet belongs to a | |||
| configured TSN Stream. If no Stream ID is matched, then the packet | configured TSN Stream. If no Stream ID is matched, then the packet | |||
| is dropped. If there is a matching TSN Stream, then the Stream ID | is dropped. If there is a matching TSN Stream, then the Stream-ID- | |||
| specific TSN functions are executed (e.g., header field manipulation | specific TSN functions are executed (e.g., header field manipulation | |||
| in case of active Stream Identification, FRER, etc.). Source MAC | in case of active Stream identification, FRER, etc.). Source MAC | |||
| lookup may also be used for local MAC address learning. | lookup may also be used for local MAC address learning. | |||
| If the PE decides to forward the packet, the packet is forwarded | If the PE decides to forward the packet, the packet is forwarded | |||
| according to the TSN Stream specific configuration to connected | according to the TSN-Stream-specific configuration to connected | |||
| CE(s). If there are no TSN Stream specific forwarding | CE(s). If there are no TSN-Stream-specific forwarding | |||
| configurations, the PE floods the packet to locally attached CE(s). | configurations, the PE floods the packet to locally attached CE(s). | |||
| If the administrative policy on the PE does not allow flooding, the | If the administrative policy on the PE does not allow flooding, the | |||
| PE drops the packet. | PE drops the packet. | |||
| Implementations of this document SHALL use management and control | Implementations of this document SHALL use management and control | |||
| information to ensure TSN specific functions of the Edge Node | information to ensure TSN-specific functions of the edge node | |||
| according to the expectations of the connected TSN network. | according to the expectations of the connected TSN network. | |||
| 5.2. Edge Node DetNet Service Proxy Procedures | 5.2. Edge Node DetNet Service Proxy Procedures | |||
| The Service Proxy function maps between App-flows and DetNet flows. | The service proxy function maps between App-flows and DetNet flows. | |||
| The DetNet Edge Node TSN entity MUST support the TSN Stream | The DetNet edge node TSN entity MUST support the TSN Stream | |||
| identification functions and the related managed objects as defined | identification functions (as defined in Clause 6 of [IEEE8021CB] and | |||
| in Clause 6. and Clause 9. of [IEEE8021CB] and [IEEEP8021CBdb] to | [IEEEP8021CBdb]) and the related managed objects (as defined in | |||
| recognize the App-flow related packets. The Service Proxy presents | Clause 9 of [IEEE8021CB] and [IEEEP8021CBdb]) to recognize the | |||
| TSN Streams as an App-flow to a DetNet Flow. | packets related to App-flow. The service proxy presents TSN Streams | |||
| as an App-flow to a DetNet flow. | ||||
| When a DetNet Service Proxy receives a packet from the TSN Entity it | When a DetNet service proxy receives a packet from the TSN entity, it | |||
| MUST check whether such an App-flow is present in its mapping table. | MUST check whether such an App-flow is present in its mapping table. | |||
| If present it associates the internal DetNet flow-ID to the packet | If present, it associates the internal DetNet flow ID to the packet | |||
| and MUST forward it to the DetNet Service and Forwarding sub-layers. | and MUST forward it to the DetNet service and forwarding sub-layers. | |||
| If no match is found it MUST drop the packet. | If no match is found, it MUST drop the packet. | |||
| When a DetNet Service Proxy receives a packet from the DetNet Service | When a DetNet service proxy receives a packet from the DetNet service | |||
| and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN | and forwarding sub-layers, it MUST be forwarded to the edge node TSN | |||
| Entity. | entity. | |||
| Implementations of this document SHALL use management and control | Implementations of this document SHALL use management and control | |||
| information to map a TSN Stream to a DetNet flow. N:1 mapping | information to map a TSN Stream to a DetNet flow. N:1 mapping | |||
| (aggregating multiple TSN Streams in a single DetNet flow) SHALL be | (aggregating multiple TSN Streams in a single DetNet flow) SHALL be | |||
| supported. The management or control function that provisions flow | supported. The management or control function that provisions flow | |||
| mapping SHALL ensure that adequate resources are allocated and | mapping SHALL ensure that adequate resources are allocated and | |||
| configured to fulfil the service requirements of the mapped flows. | configured to fulfill the service requirements of the mapped flows. | |||
| Due to the (intentional) similarities of the DetNet PREOF and TSN | Due to the (intentional) similarities of the DetNet PREOF and TSN | |||
| FRER functions service protection function interworking is possible | FRER functions, service protection function interworking is possible | |||
| between the TSN and the DetNet domains. Such service protection | between the TSN and the DetNet domains. Such service protection | |||
| interworking scenarios might require to copy sequence number fields | interworking scenarios might require copying of sequence number | |||
| from TSN (L2) to PW (MPLS) encapsulation. However, such interworking | fields from TSN (L2) to PW (MPLS) encapsulation. However, such | |||
| is out-of-scope in this document and left for further study. | interworking is out of scope in this document and is left for further | |||
| study. | ||||
| 5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures | 5.3. Edge Node DetNet Service and Forwarding Sub-Layer Procedures | |||
| In the design of [RFC8964] an MPLS service label (the S-Label), | In the design presented in [RFC8964], an MPLS service label (the | |||
| similar to a pseudowire (PW) label [RFC3985], is used to identify | S-Label), similar to a PW label [RFC3985], is used to identify both | |||
| both the DetNet flow identity and the payload MPLS payload type. The | the DetNet flow identity and the MPLS payload type. The DetNet | |||
| DetNet sequence number is carried in the DetNet Control word (d-CW) | sequence number is carried in the d-CW, which carries the Data/OAM | |||
| which carries the Data/OAM discriminator as well. In [RFC8964] two | discriminator as well. In [RFC8964], two sequence number sizes are | |||
| sequence number sizes are supported: a 16 bit sequence number and a | supported: a 16-bit sequence number and a 28-bit sequence number. | |||
| 28 bit sequence number. | ||||
| PREOF functions and the provided service recovery is available only | PREOF functions and the provided service recovery are available only | |||
| within the DetNet domain as the DetNet flow-ID and the DetNet | within the DetNet domain as the DetNet flow ID and the DetNet | |||
| sequence number are not valid outside the DetNet network. MPLS | sequence number are not valid outside the DetNet network. MPLS | |||
| (DetNet) Edge nodes terminate all related information elements | (DetNet) edge nodes terminate all related information elements | |||
| encoded in the MPLS labels. | encoded in the MPLS labels. | |||
| When a PE receives a packet from the Service Proxy function it MUST | When a PE receives a packet from the service proxy function, it MUST | |||
| handle the packet as defined in [RFC8964]. | handle the packet as defined in [RFC8964]. | |||
| When a PE receives an MPLS packet from a remote PE, then, after | When a PE receives an MPLS packet from a remote PE, then, after | |||
| processing the MPLS label stack, if the top MPLS label ends up being | processing the MPLS label stack, if the top MPLS label ends up being | |||
| a DetNet S-label that was advertised by this node, then the PE MUST | a DetNet S-Label that was advertised by this node, then the PE MUST | |||
| forward the packet according to the configured DetNet Service and | forward the packet according to the configured DetNet service and | |||
| Forwarding sub-layer rules to other PE nodes or via the Detnet | forwarding sub-layer rules to other PE nodes or via the DetNet | |||
| Service Proxy function towards locally connected CE(s). | service proxy function towards locally connected CE(s). | |||
| For further details on DetNet Service and Forwarding sub-layers see | For further details on DetNet service and forwarding sub-layers, see | |||
| [RFC8964]. | [RFC8964]. | |||
| 6. Controller Plane (Management and Control) Considerations | 6. Controller Plane (Management and Control) Considerations | |||
| TSN Stream(s) to DetNet flow mapping related information are required | Information related to TSN Stream(s) to DetNet flow mapping is | |||
| only for the service proxy function of MPLS (DetNet) Edge nodes. | required only for the service proxy function of MPLS (DetNet) edge | |||
| From the Data Plane perspective there is no practical difference | nodes. From the data plane perspective, there is no practical | |||
| based on the origin of flow mapping related information (management | difference based on the origin of flow-mapping-related information | |||
| plane or control plane). | (management plane or control plane). | |||
| The following summarizes the set of information that is needed to | The following summarizes the set of information that is needed to | |||
| configure TSN over DetNet MPLS: | configure TSN over DetNet MPLS: | |||
| o TSN related configuration information according to the TSN role of | * TSN-related configuration information according to the TSN role of | |||
| the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and | the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB], and | |||
| [IEEEP8021CBdb]. | [IEEEP8021CBdb]. | |||
| o DetNet MPLS related configuration information according to the | * DetNet MPLS-related configuration information according to the | |||
| DetNet role of the DetNet MPLS node, as per [RFC8964]. | DetNet role of the DetNet MPLS node, as per [RFC8964]. | |||
| o App-Flow identification information to map received TSN Stream(s) | * App-flow identification information to map received TSN Stream(s) | |||
| to the DetNet flow. Parameters of TSN stream identification are | to the DetNet flow. Parameters of TSN Stream identification are | |||
| defined in [IEEE8021CB] and [IEEEP8021CBdb]. | defined in [IEEE8021CB] and [IEEEP8021CBdb]. | |||
| This information MUST be provisioned per DetNet flow. | This information MUST be provisioned per DetNet flow. | |||
| Mappings between DetNet and TSN management and control planes are out | Mappings between DetNet and TSN management and control planes are out | |||
| of scope of the document. Some of the challanges are highligthed | of scope of the document. Some of the challenges are highlighted | |||
| below. | below. | |||
| MPLS DetNet Edge nodes are member of both the DetNet domain and the | MPLS DetNet edge nodes are a member of both the DetNet domain and the | |||
| connected TSN network. From the TSN network perspective the MPLS | connected TSN network. From the TSN network perspective, the MPLS | |||
| (DetNet) Edge node has a "TSN relay node" role, so TSN specific | (DetNet) edge node has a "TSN relay node" role, so TSN-specific | |||
| management and control plane functionalities must be implemented. | management and control plane functionalities must be implemented. | |||
| There are many similarities in the management plane techniques used | There are many similarities in the management plane techniques used | |||
| in DetNet and TSN, but that is not the case for the control plane | in DetNet and TSN, but that is not the case for the control plane | |||
| protocols. For example, RSVP-TE and MSRP behaves differently. | protocols. For example, RSVP-TE and MSRP behave differently. | |||
| Therefore management and control plane design is an important aspect | Therefore, management and control plane design is an important aspect | |||
| of scenarios, where mapping between DetNet and TSN is required. | of scenarios where mapping between DetNet and TSN is required. | |||
| Note that, as the DetNet network is just a portion of the end to end | Note that as the DetNet network is just a portion of the end-to-end | |||
| TSN path (i.e., single hop from Ethernet perspective), some | TSN path (i.e., single hop from the Ethernet perspective), some | |||
| parameters (e.g., delay) may differ significantly. Since there is no | parameters (e.g., delay) may differ significantly. Since there is no | |||
| interworking function the bandwidth of DetNet network is assumed to | interworking function, the bandwidth of the DetNet network is assumed | |||
| be set large enough to handle all TSN Flows it will support. At the | to be set large enough to handle all TSN flows it will support. At | |||
| egress of the Detnet Domain the MPLS headers are stripped and the TSN | the egress of the DetNet domain, the MPLS headers are stripped, and | |||
| flow continues on as a normal TSN flow. | the TSN flow continues on as a normal TSN flow. | |||
| In order to use a DetNet network to interconnect TSN segments, TSN | In order to use a DetNet network to interconnect TSN segments, TSN- | |||
| specific information must be converted to DetNet domain specific | specific information must be converted to DetNet-domain-specific | |||
| ones. TSN Stream ID(s) and stream(s) related parameters/requirements | information. TSN Stream ID(s) and stream-related parameters/ | |||
| must be converted to a DetNet flow-ID and flow related parameters/ | requirements must be converted to a DetNet flow ID and flow-related | |||
| requirements. | parameters/requirements. | |||
| In some case it may be challenging to determine some egress node | In some cases, it may be challenging to determine some information | |||
| related information. For example, it may be not trivial to locate | related to the egress-node. For example, it may be not trivial to | |||
| the egress point/interface of a TSN Stream with a multicast | locate the egress point/interface of a TSN Stream with a multicast | |||
| destination MAC address. Such scenarios may require interaction | destination MAC address. Such scenarios may require interaction | |||
| between control and management plane functions and between DetNet and | between control and management plane functions and between DetNet and | |||
| TSN domains. | TSN domains. | |||
| Mapping between DetNet flow identifiers and TSN Stream identifiers, | Mapping between DetNet flow identifiers and TSN Stream identifiers, | |||
| if not provided explicitly, can be done by the service proxy function | if not provided explicitly, can be done by the service proxy function | |||
| of an MPLS (DetNet) Edge node locally based on information provided | of an MPLS (DetNet) edge node locally based on information provided | |||
| for configuration of the TSN Stream identification functions (e.g., | for the configuration of the TSN Stream identification functions | |||
| Mask-and-Match Stream identification). | (e.g., Mask-and-Match Stream identification). | |||
| Triggering the setup/modification of a DetNet flow in the DetNet | Triggering the setup/modification of a DetNet flow in the DetNet | |||
| network is an example where management and/or control plane | network is an example where management and/or control plane | |||
| interactions are required between the DetNet and the TSN network. | interactions are required between the DetNet and the TSN network. | |||
| Configuration of TSN specific functions (e.g., FRER) inside the TSN | Configuration of TSN-specific functions (e.g., FRER) inside the TSN | |||
| network is a TSN domain specific decision and may not be visible in | network is a TSN-domain-specific decision and may not be visible in | |||
| the DetNet domain. Service protection interworking scenarios are | the DetNet domain. Service protection interworking scenarios are | |||
| left for further study. | left for further study. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| Security considerations for DetNet are described in detail in | Security considerations for DetNet are described in detail in | |||
| [I-D.ietf-detnet-security]. General security considerations are | [DETNET-SEC]. General security considerations are described in | |||
| described in [RFC8655]. | [RFC8655]. | |||
| DetNet MPLS data plane specific considerations are summarized and | Considerations specific to the DetNet MPLS data plane are summarized | |||
| described in [RFC8964] including any application flow types. This | and described in [RFC8964], including any application flow types. | |||
| document focuses on the scenario where TSN Streams are the | This document focuses on a scenario where TSN Streams are the | |||
| application flows for DetNet and it is already covered by those | application flows for DetNet, which is already covered by those | |||
| DetNet MPLS data plane security considerations. | DetNet MPLS data plane security considerations. | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| This document makes no IANA requests. | This document has no IANA actions. | |||
| 9. Acknowledgements | ||||
| The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, | ||||
| Christophe Mangin and Jouni Korhonen for their various contributions | ||||
| to this work. | ||||
| 10. References | 9. References | |||
| 10.1. Normative References | 9.1. Normative References | |||
| [IEEE8021CB] | [IEEE8021CB] | |||
| IEEE 802.1, "Standard for Local and metropolitan area | IEEE, "Standard for Local and metropolitan area networks | |||
| networks - Frame Replication and Elimination for | -- Frame Replication and Elimination for Reliability", | |||
| Reliability (IEEE Std 802.1CB-2017)", 2017, | IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, | |||
| <http://standards.ieee.org/about/get/>. | October 2017, | |||
| <https://ieeexplore.ieee.org/document/8091139>. | ||||
| [IEEEP8021CBdb] | [IEEEP8021CBdb] | |||
| Mangin, C., "Extended Stream identification functions", | IEEE, "Draft Standard for Local and metropolitan area | |||
| IEEE P802.1CBdb /D1.0 P802.1CBdb, September 2020, | networks - Frame Replication and Elimination for | |||
| <http://www.ieee802.org/1/files/private/db-drafts/d1/802- | Reliability - Amendment: Extended Stream Identification | |||
| 1CBdb-d1-0.pdf>. | Functions", IEEE P802.1CBdb D1.3, April 2021, | |||
| <https://1.ieee802.org/tsn/802-1cbdb>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
| Label Switching Architecture", RFC 3031, | Label Switching Architecture", RFC 3031, | |||
| DOI 10.17487/RFC3031, January 2001, | DOI 10.17487/RFC3031, January 2001, | |||
| <https://www.rfc-editor.org/info/rfc3031>. | <https://www.rfc-editor.org/info/rfc3031>. | |||
| skipping to change at page 14, line 15 ¶ | skipping to change at line 589 ¶ | |||
| [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | [RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. | |||
| Bryant, "Deterministic Networking (DetNet) Data Plane | Bryant, "Deterministic Networking (DetNet) Data Plane | |||
| Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, | Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, | |||
| <https://www.rfc-editor.org/info/rfc8938>. | <https://www.rfc-editor.org/info/rfc8938>. | |||
| [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, | [RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, | |||
| S., and J. Korhonen, "Deterministic Networking (DetNet) | S., and J. Korhonen, "Deterministic Networking (DetNet) | |||
| Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January | Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January | |||
| 2021, <https://www.rfc-editor.org/info/rfc8964>. | 2021, <https://www.rfc-editor.org/info/rfc8964>. | |||
| 10.2. Informative References | 9.2. Informative References | |||
| [I-D.ietf-detnet-security] | [DETNET-SEC] | |||
| Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic | Grossman, E., Ed., Mizrahi, T., and A. Hacker, | |||
| Networking (DetNet) Security Considerations", draft-ietf- | "Deterministic Networking (DetNet) Security | |||
| detnet-security-13 (work in progress), December 2020. | Considerations", Work in Progress, Internet-Draft, draft- | |||
| ietf-detnet-security-16, 2 March 2021, | ||||
| <https://tools.ietf.org/html/draft-ietf-detnet-security- | ||||
| 16>. | ||||
| [IEEE8021Q] | [IEEE8021Q] | |||
| IEEE 802.1, "Standard for Local and metropolitan area | IEEE, "Standard for Local and Metropolitan Area Networks-- | |||
| networks--Bridges and Bridged Networks (IEEE Std 802.1Q- | Bridges and Bridged Networks", IEEE Std. 802.1Q-2018, | |||
| 2018)", 2018, <http://standards.ieee.org/about/get/>. | DOI 10.1109/IEEESTD.2018.8403927, July 2018, | |||
| <https://ieeexplore.ieee.org/document/8403927>. | ||||
| [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation | [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation | |||
| Edge-to-Edge (PWE3) Architecture", RFC 3985, | Edge-to-Edge (PWE3) Architecture", RFC 3985, | |||
| DOI 10.17487/RFC3985, March 2005, | DOI 10.17487/RFC3985, March 2005, | |||
| <https://www.rfc-editor.org/info/rfc3985>. | <https://www.rfc-editor.org/info/rfc3985>. | |||
| Acknowledgements | ||||
| The authors wish to thank Norman Finn, Lou Berger, Craig Gunther, | ||||
| Christophe Mangin, and Jouni Korhonen for their various contributions | ||||
| to this work. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Balazs Varga (editor) | Balázs Varga (editor) | |||
| Ericsson | Ericsson | |||
| Budapest | ||||
| Magyar Tudosok krt. 11. | Magyar Tudosok krt. 11. | |||
| Budapest 1117 | 1117 | |||
| Hungary | Hungary | |||
| Email: balazs.a.varga@ericsson.com | Email: balazs.a.varga@ericsson.com | |||
| Janos Farkas | János Farkas | |||
| Ericsson | Ericsson | |||
| Budapest | ||||
| Magyar Tudosok krt. 11. | Magyar Tudosok krt. 11. | |||
| Budapest 1117 | 1117 | |||
| Hungary | Hungary | |||
| Email: janos.farkas@ericsson.com | Email: janos.farkas@ericsson.com | |||
| Andrew G. Malis | Andrew G. Malis | |||
| Malis Consulting | Malis Consulting | |||
| Email: agmalis@gmail.com | Email: agmalis@gmail.com | |||
| Stewart Bryant | Stewart Bryant | |||
| Futurewei Technologies | Futurewei Technologies | |||
| Email: stewart.bryant@gmail.com | Email: sb@stewartbryant.com | |||
| Don Fedyk | Don Fedyk | |||
| LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
| Email: dfedyk@labn.net | Email: dfedyk@labn.net | |||
| End of changes. 117 change blocks. | ||||
| 272 lines changed or deleted | 285 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||