| < draft-ietf-detnet-mpls-07.txt | draft-ietf-detnet-mpls-08.txt > | |||
|---|---|---|---|---|
| DetNet B. Varga, Ed. | DetNet B. Varga, Ed. | |||
| Internet-Draft J. Farkas | Internet-Draft J. Farkas | |||
| Intended status: Standards Track Ericsson | Intended status: Standards Track Ericsson | |||
| Expires: December 10, 2020 L. Berger | Expires: January 7, 2021 L. Berger | |||
| LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
| A. Malis | A. Malis | |||
| Malis Consulting | Malis Consulting | |||
| S. Bryant | S. Bryant | |||
| Futurewei Technologies | Futurewei Technologies | |||
| J. Korhonen | J. Korhonen | |||
| June 8, 2020 | July 6, 2020 | |||
| DetNet Data Plane: MPLS | DetNet Data Plane: MPLS | |||
| draft-ietf-detnet-mpls-07 | draft-ietf-detnet-mpls-08 | |||
| Abstract | Abstract | |||
| This document specifies the Deterministic Networking data plane when | This document specifies the Deterministic Networking data plane when | |||
| operating over an MPLS Packet Switched Networks. | operating over an MPLS Packet Switched Networks. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on December 10, 2020. | This Internet-Draft will expire on January 7, 2021. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 | 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 | |||
| 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 | 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 | |||
| 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 | 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 | |||
| 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 | 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 | |||
| 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 | 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 | |||
| 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 | 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 | |||
| 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 | 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 | |||
| 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 | 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 | |||
| 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 | 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 | 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 16 | 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 | 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 17 | |||
| 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 | 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 17 | |||
| 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 | 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 18 | |||
| 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 | 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 19 | |||
| 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 | 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 19 | |||
| 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19 | 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 19 | |||
| 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 | 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 20 | |||
| 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 | 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 20 | |||
| 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 20 | 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 | |||
| 5. Management and Control Information Summary . . . . . . . . . 21 | 5. Management and Control Information Summary . . . . . . . . . 21 | |||
| 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22 | 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 22 | |||
| 5.1.1. Service Aggregation Information Summary . . . . . . . 23 | 5.1.1. Service Aggregation Information Summary . . . . . . . 23 | |||
| 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 | 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 23 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . 27 | 10.2. Informative References . . . . . . . . . . . . . . . . . 27 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 1. Introduction | 1. Introduction | |||
| Deterministic Networking (DetNet) is a service that can be offered by | Deterministic Networking (DetNet) is a service that can be offered by | |||
| a network to DetNet flows. DetNet provides these flows extremely low | a network to DetNet flows. DetNet provides these flows extremely low | |||
| packet loss rates and assured maximum end-to-end delivery latency. | packet loss rates and assured maximum end-to-end delivery latency. | |||
| General background and concepts of DetNet can be found in [RFC8655]. | General background and concepts of DetNet can be found in [RFC8655]. | |||
| The DetNet Architecture models the DetNet related data plane | The DetNet Architecture models the DetNet related data plane | |||
| functions decomposed into two sub-layers: a service sub-layer and a | functions decomposed into two sub-layers: a service sub-layer and a | |||
| skipping to change at page 3, line 46 ¶ | skipping to change at page 3, line 46 ¶ | |||
| Background information common to all data planes for DetNet can be | Background information common to all data planes for DetNet can be | |||
| found in the DetNet Data Plane Framework | found in the DetNet Data Plane Framework | |||
| [I-D.ietf-detnet-data-plane-framework]. | [I-D.ietf-detnet-data-plane-framework]. | |||
| 2. Terminology | 2. Terminology | |||
| 2.1. Terms Used in This Document | 2.1. Terms Used in This Document | |||
| This document uses the terminology established in the DetNet | This document uses the terminology established in the DetNet | |||
| architecture [RFC8655] and the the DetNet Data Plane Framework | architecture [RFC8655] and the DetNet Data Plane Framework | |||
| [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be | [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be | |||
| familiar with these documents, any terminology defined therein and | familiar with these documents, any terminology defined therein and | |||
| basic MPLS related terminologies in [RFC3031]. | basic MPLS related terminologies in [RFC3031]. | |||
| The following terminology is introduced in this document: | The following terminology is introduced in this document: | |||
| F-Label A Detnet "forwarding" label that identifies the LSP | F-Label A Detnet "forwarding" label that identifies the LSP | |||
| used to forward a DetNet flow across an MPLS PSN, e.g., | used to forward a DetNet flow across an MPLS PSN, e.g., | |||
| a hop-by-hop label used between label switching routers | a hop-by-hop label used between label switching routers | |||
| (LSR). | (LSR). | |||
| S-Label A DetNet "service" label that is used between DetNet | S-Label A DetNet "service" label that is used between DetNet | |||
| nodes that implement also the DetNet service sub-layer | nodes that implement also the DetNet service sub-layer | |||
| functions. An S-Label is also used to identify a | functions. An S-Label is also used to identify a | |||
| DetNet flow at DetNet service sub-layer. | DetNet flow at DetNet service sub-layer at a receiving | |||
| DetNet node. | ||||
| A-Label A special case of an S-Label, whose aggregation | A-Label A special case of an S-Label, whose aggregation | |||
| properties are known only at the aggregation and | properties are known only at the aggregation and | |||
| deaggregation end-points. | deaggregation end-points. | |||
| d-CW A DetNet Control Word (d-CW) is used for sequencing | d-CW A DetNet Control Word (d-CW) is used for sequencing | |||
| information of a DetNet flow at the DetNet service sub- | information of a DetNet flow at the DetNet service sub- | |||
| layer. | layer. | |||
| 2.2. Abbreviations | 2.2. Abbreviations | |||
| skipping to change at page 6, line 6 ¶ | skipping to change at page 6, line 6 ¶ | |||
| | Service | d-CW, S-Label (A-Label) | | Service | d-CW, S-Label (A-Label) | |||
| +------------+ | +------------+ | |||
| | Forwarding | F-Label(s) | | Forwarding | F-Label(s) | |||
| +------------+ | +------------+ | |||
| Top of Stack . | Top of Stack . | |||
| (outer label) . | (outer label) . | |||
| Figure 1: DetNet Adaptation to MPLS Data Plane | Figure 1: DetNet Adaptation to MPLS Data Plane | |||
| The DetNet MPLS data plane representation is illustrated in Figure 1. | The DetNet MPLS data plane representation is illustrated in Figure 1. | |||
| The service sub-layer includes a DetNet control word (d-CW) and a | The service sub-layer includes a DetNet control word (d-CW) and an | |||
| identifying service label (S-Label). The DetNet control word (d-CW) | identifying service label (S-Label). The DetNet control word (d-CW) | |||
| conforms to the Generic PW MPLS Control Word (PWMCW) defined in | conforms to the Generic PW MPLS Control Word (PWMCW) defined in | |||
| [RFC4385]. An aggregation label (A-Label) is a special case of | [RFC4385]. An aggregation label (A-Label) is a special case of | |||
| S-Label used for aggregation. | S-Label used for aggregation. | |||
| A node operating on a DetNet flow in the Detnet service sub-layer, | A node operating on a received DetNet flow at the Detnet service sub- | |||
| uses the local context associated with that S-Label, provided by a | layer uses the local context associated with a received S-Label, | |||
| received F-Label, to determine what local DetNet operation(s) are | i.e., a received F-Label, to determine which local DetNet | |||
| applied to that packet. An S-Label may be taken from the platform | operation(s) are applied to that packet. An S-Label may be taken | |||
| label space [RFC3031], making it unique, enabling DetNet flow | from the platform label space [RFC3031], making it unique, enabling | |||
| identification regardless of which input interface or LSP the packet | DetNet flow identification regardless of which input interface or LSP | |||
| arrives on. | the packet arrives on. It is important to note that S-Label values | |||
| are driven by the receiver, not the sender. | ||||
| The DetNet forwarding sub-layer is supported by zero or more | The DetNet forwarding sub-layer is supported by zero or more | |||
| forwarding labels (F-Labels). MPLS Traffic Engineering | forwarding labels (F-Labels). MPLS Traffic Engineering | |||
| encapsulations and mechanisms can be utilized to provide a forwarding | encapsulations and mechanisms can be utilized to provide a forwarding | |||
| sub-layer that is responsible for providing resource allocation and | sub-layer that is responsible for providing resource allocation and | |||
| explicit routes. | explicit routes. | |||
| 3.2. DetNet MPLS Data Plane Scenarios | 3.2. DetNet MPLS Data Plane Scenarios | |||
| DetNet MPLS Relay Transit Relay DetNet MPLS | DetNet MPLS Relay Transit Relay DetNet MPLS | |||
| skipping to change at page 7, line 5 ¶ | skipping to change at page 7, line 7 ¶ | |||
| |<----------------- DetNet MPLS --------------------->| | |<----------------- DetNet MPLS --------------------->| | |||
| Figure 2: A DetNet MPLS Network | Figure 2: A DetNet MPLS Network | |||
| Figure 2 illustrates a hypothetical DetNet MPLS-only network composed | Figure 2 illustrates a hypothetical DetNet MPLS-only network composed | |||
| of DetNet aware MPLS enabled end systems, operating over a DetNet | of DetNet aware MPLS enabled end systems, operating over a DetNet | |||
| aware MPLS network. In this figure, the relay nodes are PE devices | aware MPLS network. In this figure, the relay nodes are PE devices | |||
| that define the MPLS LSP boundaries and the transit nodes are LSRs. | that define the MPLS LSP boundaries and the transit nodes are LSRs. | |||
| DetNet end system and relay nodes understand the particular needs of | DetNet end systems and relay nodes understand the particular needs of | |||
| DetNet flows and provide both DetNet service and forwarding sub-layer | DetNet flows and provide both DetNet service and forwarding sub-layer | |||
| functions. In the case of MPLS, DetNet service-aware nodes add, | functions. In the case of MPLS, DetNet service-aware nodes add, | |||
| remove and process d-CWs, S-Labels and F-labels as needed. DetNet | remove and process d-CWs, S-Labels and F-labels as needed. DetNet | |||
| MPLS nodes provide functionality analogous to T-PEs when they sit at | MPLS nodes provide functionality analogous to T-PEs when they sit at | |||
| the edge of an MPLS domain, and S-PEs when they are in the middle of | the edge of an MPLS domain, and S-PEs when they are in the middle of | |||
| an MPLS domain, see [RFC6073]. | an MPLS domain, see [RFC6073]. | |||
| In a DetNet MPLS network, transit nodes may be DetNet service aware | In a DetNet MPLS network, transit nodes may be DetNet service aware | |||
| or may be DetNet unaware MPLS Label Switching Routers (LSRs). In | or may be DetNet unaware MPLS Label Switching Routers (LSRs). In | |||
| this latter case, such LSRs would be unaware of the special | this latter case, such LSRs would be unaware of the special | |||
| skipping to change at page 8, line 50 ¶ | skipping to change at page 8, line 50 ¶ | |||
| 3. A method of distinguishing DetNet OAM packets from DetNet data | 3. A method of distinguishing DetNet OAM packets from DetNet data | |||
| packets. | packets. | |||
| 4. A method of carrying the DetNet sequence number. | 4. A method of carrying the DetNet sequence number. | |||
| 5. A suitable LSP to deliver the packet to the egress PE. | 5. A suitable LSP to deliver the packet to the egress PE. | |||
| 6. A method of carrying queuing and forwarding indication. | 6. A method of carrying queuing and forwarding indication. | |||
| In this design an MPLS service label (the S-Label), similar to a | In this design an MPLS service label (the S-Label), is similar to a | |||
| pseudowire (PW) label [RFC3985], is used to identify both the DetNet | pseudowire (PW) label [RFC3985], and is used to identify both the | |||
| flow identity and the payload MPLS payload type satisfying (1) and | DetNet flow identity and the payload MPLS payload type satisfying (1) | |||
| (2) in the list above. OAM traffic discrimination happens through | and (2) in the list above. OAM traffic discrimination happens | |||
| the use of the Associated Channel method described in [RFC4385]. The | through the use of the Associated Channel method described in | |||
| DetNet sequence number is carried in the DetNet Control word which | [RFC4385]. The DetNet sequence number is carried in the DetNet | |||
| carries the Data/OAM discriminator. To simplify implementation and | Control word which carries the Data/OAM discriminator. To simplify | |||
| to maximize interoperability two sequence number sizes are supported: | implementation and to maximize interoperability two sequence number | |||
| a 16 bit sequence number and a 28 bit sequence number. The 16 bit | sizes are supported: a 16 bit sequence number and a 28 bit sequence | |||
| sequence number is needed to support some types of legacy clients. | number. The 16 bit sequence number is needed to support some types | |||
| The 28 bit sequence number is used in situations where it is | of legacy clients. The 28 bit sequence number is used in situations | |||
| necessary ensure that in high speed networks the sequence number | where it is necessary ensure that in high speed networks the sequence | |||
| space does not wrap whilst packets are in flight. | number space does not wrap whilst packets are in flight. | |||
| The LSP used to forward the DetNet packet is not restricted regarding | The LSP used to forward the DetNet packet is not restricted regarding | |||
| any method used for establishing that LSP (for example, MPLS-LDP, | any method used for establishing that LSP (for example, MPLS-LDP, | |||
| MPLS-TE, MPLS-TP [RFC5921], MPLS-SR [RFC8660], etc.). The LSP | MPLS-TE, MPLS-TP [RFC5921], MPLS-SR [RFC8660], etc.). The LSP | |||
| (F-Label) label and/or the S-Label may be used to indicate the queue | (F-Label) label(s) and/or the S-Label may be used to indicate the | |||
| processing as well as the forwarding parameters. Note that the | required queue processing as well as the forwarding parameters. Note | |||
| possible use of Penultimate Hop Popping (PHP) means that the S-Label | that the possible use of Penultimate Hop Popping (PHP) means that the | |||
| may be the only label received at the terminating DetNet service. | S-Label may be the only label received at the terminating DetNet | |||
| service. | ||||
| 4.2. MPLS Data Plane Encapsulation | 4.2. MPLS Data Plane Encapsulation | |||
| Figure 4 illustrates a DetNet data plane MPLS encapsulation. The | Figure 4 illustrates a DetNet data plane MPLS encapsulation. The | |||
| MPLS-based encapsulation of the DetNet flows is well suited for the | MPLS-based encapsulation of the DetNet flows is well suited for the | |||
| scenarios described in [I-D.ietf-detnet-data-plane-framework]. | scenarios described in [I-D.ietf-detnet-data-plane-framework]. | |||
| Furthermore, an end to end DetNet service i.e., native DetNet | Furthermore, an end to end DetNet service i.e., native DetNet | |||
| deployment (see Section 3.2) is also possible if DetNet end systems | deployment (see Section 3.2) is also possible if DetNet end systems | |||
| are capable of initiating and termination MPLS encapsulated packets. | are capable of initiating and termination MPLS encapsulated packets. | |||
| skipping to change at page 9, line 43 ¶ | skipping to change at page 9, line 44 ¶ | |||
| o DetNet control word (d-CW) containing sequencing information for | o DetNet control word (d-CW) containing sequencing information for | |||
| packet replication and duplicate elimination purposes, and the OAM | packet replication and duplicate elimination purposes, and the OAM | |||
| indicator. | indicator. | |||
| o DetNet service Label (S-Label) that identifies a DetNet flow at | o DetNet service Label (S-Label) that identifies a DetNet flow at | |||
| the receiving DetNet service sub-layer processing node. | the receiving DetNet service sub-layer processing node. | |||
| o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to | o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to | |||
| direct the packet along the label switched path (LSP) to the next | direct the packet along the label switched path (LSP) to the next | |||
| service sub-layer processing node along the path. When | DetNet service sub-layer processing node along the path. When | |||
| Penultimate Hop Popping is in use there may be no label F-Label in | Penultimate Hop Popping is in use there may be no label F-Label in | |||
| the protocol stack on the final hop. | the protocol stack on the final hop. | |||
| o The necessary data-link encapsulation is then applied prior to | o The necessary data-link encapsulation is then applied prior to | |||
| transmission over the physical media. | transmission over the physical media. | |||
| DetNet MPLS-based encapsulation | DetNet MPLS-based encapsulation | |||
| +---------------------------------+ | +---------------------------------+ | |||
| | | | | | | |||
| skipping to change at page 11, line 6 ¶ | skipping to change at page 11, line 6 ¶ | |||
| (bits 0 to 3) | (bits 0 to 3) | |||
| Per [RFC4385], MUST be set to zero (0). | Per [RFC4385], MUST be set to zero (0). | |||
| Sequence Number (bits 4 to 31) | Sequence Number (bits 4 to 31) | |||
| An unsigned value implementing the DetNet sequence number. The | An unsigned value implementing the DetNet sequence number. The | |||
| sequence number space is a circular one. | sequence number space is a circular one. | |||
| A separate sequence number space MUST be maintained by the node that | A separate sequence number space MUST be maintained by the node that | |||
| adds the d-CW for each DetNet app-flow. The following sequence | adds the d-CW for each DetNet app-flow, i.e., DetNet service. The | |||
| number field lengths MUST be supported: | following sequence number field lengths MUST be supported: | |||
| 0 bits | 0 bits | |||
| 16 bits | 16 bits | |||
| 28 bits | 28 bits | |||
| The sequence number length MUST be provisioned on a per app-flow | The sequence number length MUST be provisioned on a per Detnet | |||
| basis via configuration, i.e., via the controller plane described in | service basis via configuration, i.e., via the controller plane | |||
| [I-D.ietf-detnet-data-plane-framework]. | described in [I-D.ietf-detnet-data-plane-framework]. | |||
| A 0 bit sequence number field length indicates that there is no | A 0 bit sequence number field length indicates that there is no | |||
| DetNet sequence number used for the flow. When the length is zero, | DetNet sequence number used for the flow. When the length is zero, | |||
| the sequence number field MUST be set to zero (0) on all packets sent | the sequence number field MUST be set to zero (0) on all packets sent | |||
| for the flow. | for the flow. | |||
| When the sequence number field length is 16 or 28 bits for a flow, | When the sequence number field length is 16 or 28 bits for a flow, | |||
| the sequence number MUST be incremented by one for each new app-flow | the sequence number MUST be incremented by one for each new app-flow | |||
| packet sent. When the field length is 16 bits, d-CW bits 4 to 15 | packet sent. When the field length is 16 bits, d-CW bits 4 to 15 | |||
| MUST be set to zero (0). The values carried in this field can wrap | MUST be set to zero (0). The values carried in this field can wrap | |||
| and it is important to note that zero (0) is a valid field value. | and it is important to note that zero (0) is a valid field value. | |||
| For example, were the sequence number size is 16 bits, the sequence | For example, were the sequence number size is 16 bits, the sequence | |||
| will contain: 65535, 0, 1, where zero (0) is an ordinary sequence | will contain: 65535, 0, 1, where zero (0) is an ordinary sequence | |||
| number. | number. | |||
| It is important to note that this document differs from [RFC4448] | It is important to note that this document differs from [RFC4448] | |||
| where a sequence number of zero (0) is used to indicate that the | where a sequence number of zero (0) is used to indicate that the | |||
| sequence number check algorithm is not used. | sequence number check algorithm is not used. | |||
| The sequence number is optionally used during receive processing as | The sequence number is optionally used during receive processing as | |||
| described below in Section 4.2.2.1 and Section 4.2.2.2. | described below in Section 4.2.2.2 and Section 4.2.2.3. | |||
| 4.2.2. S-Labels | 4.2.2. S-Labels | |||
| App-flow identification at a DetNet service sub-layer is realized by | A DetNet flow at the DetNet service sub-layer is identified by an | |||
| an S-Label. MPLS-aware DetNet end systems and edge nodes, which are | S-Label. MPLS-aware DetNet end systems and edge nodes, which are by | |||
| by definition MPLS ingress and egress nodes, MUST add and remove an | definition MPLS ingress and egress nodes, MUST add (push) and remove | |||
| app-flow specific d-CW and S-Label. Relay nodes MAY swap S-Label | (pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY | |||
| values when processing an app-flow. | swap S-Label values when processing a DetNet flow, i.e., incoming and | |||
| outgoing S-Labels of a DetNet flow can be different. | ||||
| The S-Label value MUST be provisioned per app-flow via configuration, | S-Label values MUST be provisioned per DetNet service via | |||
| e.g., via the controller plane described in | configuration, e.g., via the controller plane described in | |||
| [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide | [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide | |||
| app-flow identification at the downstream DetNet service sub-layer | identification at the downstream DetNet service sub-layer receiver, | |||
| receiver, not the sender. As such, S-Labels MUST be allocated by the | not the sender. As such, S-Labels MUST be allocated by the entity | |||
| entity that controls the service sub-layer receiving node's label | that controls the service sub-layer receiving node's label space, and | |||
| space, and MAY be allocated from the platform label space [RFC3031]. | MAY be allocated from the platform label space [RFC3031]. Because | |||
| Because S-Labels are local to each node rather than being a global | S-Labels are local to each node rather than being a global identifier | |||
| identifier within a domain, they must be advertised to their upstream | within a domain, they must be advertised to their upstream DetNet | |||
| DetNet service-aware peer nodes (e.g., a DetNet MPLS End System or a | service-aware peer nodes (e.g., a DetNet MPLS End System or a DetNet | |||
| DetNet Relay or Edge Node and interpreted in the context of their | Relay or Edge Node) and interpreted in the context of their received | |||
| received F-Label. | F-Label(s). | |||
| The S-Label will normally be at the bottom of the label stack once | An S-Label will normally be at the bottom of the label stack once the | |||
| the last F-Label is removed, immediately preceding the d-CW. To | last F-Label is removed, immediately preceding the d-CW. To support | |||
| support service sub-layer level OAM, an OAM Associated Channel Header | service sub-layer level OAM, an OAM Associated Channel Header (ACH) | |||
| (ACH) [RFC4385] together with a Generic Associated Channel Label | [RFC4385] together with a Generic Associated Channel Label (GAL) | |||
| (GAL) [RFC5586] MAY be used in place of a d-CW. | [RFC5586] MAY be used in place of a d-CW. | |||
| Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) | Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) | |||
| [RFC6790] MAY be carried below the S-Label in the label stack in | [RFC6790] MAY be carried below the S-Label in the label stack in | |||
| networks where DetNet flows would otherwise received ECMP treatment. | networks where DetNet flows would otherwise received ECMP treatment. | |||
| When ELs are used, the same EL value SHOULD be used for all of the | When ELs are used, the same EL value SHOULD be used for all of the | |||
| packets sent using a specific S-Label to force the flow to follow the | packets sent using a specific S-Label to force the flow to follow the | |||
| same path. However, as outlines in | same path. However, as outlines in | |||
| [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet | [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet | |||
| flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows | flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows | |||
| within a DetNet domain. | within a DetNet domain. | |||
| When receiving a DetNet MPLS flow, an implementation MUST identify | When receiving a DetNet MPLS packet, an implementation MUST identify | |||
| the app-flow associated with the incoming packet based on the | the DetNet service associated with the incoming packet based on the | |||
| S-Label. When a node is using platform labels for S-Labels, no | S-Label. When a node is using platform labels for S-Labels, no | |||
| additional information is needed as the S-label uniquely identifies | additional information is needed as the S-label uniquely identifies | |||
| the app-flow. In the case where platform labels are not used, zero | the DetNet service. In the case where platform labels are not used, | |||
| or more F-Labels and optionally, the incoming interface, proceeding | zero or more F-Labels and optionally, the incoming interface, | |||
| the S-Label MUST be used together with the S-Label to uniquely | proceeding the S-Label MUST be used together with the S-Label to | |||
| identify the app-flows associated with a received packet. The | uniquely identify the DetNet service associated with a received | |||
| incoming interface MAY also be used to together with any present | packet. The incoming interface MAY also be used together with any | |||
| F-Label(s) and the S-Label to uniquely identify an incoming app- | present F-Label(s) and the S-Label to uniquely identify an incoming | |||
| flows, for example, to in the case where PHP is used. Note that | DetNet service, for example, in the case where PHP is used. Note | |||
| choice to use platform label space for S-Label or S-Label plus one or | that choice to use platform label space for S-Label or S-Label plus | |||
| more F-Labels to identify app flows is a local implementation choice, | one or more F-Labels to identify DetNet services is a local | |||
| with one caveat. When one or more F-labels, or incoming interface, | implementation choice, with one caveat. When one or more F-labels, | |||
| is needed together with an S-Label to uniquely identify, the | or incoming interface, is needed together with an S-Label to uniquely | |||
| controller plane MUST ensure that incoming DetNet MPLS packets arrive | identify a service, the controller plane must ensure that incoming | |||
| with the needed information (F-label(s) and/or incoming interface); | DetNet MPLS packets arrive with the needed information (F-label(s) | |||
| the details of such are outside the scope of this document. | and/or incoming interface) and provision the needed information. The | |||
| provisioned information MUST then be used to identify incoming DetNet | ||||
| service based on the combination of S-Label and F-Label(s) or | ||||
| incoming interface. | ||||
| The use of platform labels for S-Labels matches other pseudowire | The use of platform labels for S-Labels matches other pseudowire | |||
| encapsulations for consistency but there is no hard requirement in | encapsulations for consistency but there is no hard requirement in | |||
| this regard. | this regard. | |||
| 4.2.2.1. Packet Elimination Function Processing | 4.2.2.1. Packet Replication Function Processing | |||
| The Packet Replication Function (PRF) function MAY be supported by an | ||||
| implementation for outgoing DetNet flows. The use of the PRF for a | ||||
| particular DetNet service MUST be provisioned via configuration, | ||||
| e.g., via the controller plane described in | ||||
| [I-D.ietf-detnet-data-plane-framework]. When replication is | ||||
| configure, the same app-flow data will be sent over multiple outgoing | ||||
| DetNet member flows using forwarding sub-layer LSPs. The same d-CW | ||||
| field value MUST be used on all outgoing member flows for each | ||||
| replicated MPLS packet. | ||||
| 4.2.2.2. Packet Elimination Function Processing | ||||
| Implementations MAY support the Packet Elimination Function (PEF) for | Implementations MAY support the Packet Elimination Function (PEF) for | |||
| received DetNet MPLS flows. When supported, use of the PEF for a | received DetNet MPLS flows. When supported, use of the PEF for a | |||
| particular app-flow MUST be provisioned via configuration, e.g., via | particular DetNet service MUST be provisioned via configuration, | |||
| the controller plane described in | e.g., via the controller plane described in | |||
| [I-D.ietf-detnet-data-plane-framework]. | [I-D.ietf-detnet-data-plane-framework]. | |||
| After an app-flow is identified for a received DetNet MPLS packet, as | After a DetNet service is identified for a received DetNet MPLS | |||
| described above, an implementation MUST check if PEF is configured | packet, as described above, an implementation MUST check if PEF is | |||
| for that app-flow. When configured, the implementation MUST track | configured for that DetNet service. When configured, the | |||
| the sequence number contained in received d-CWs and MUST ensure that | implementation MUST track the sequence number contained in received | |||
| duplicate (replicated) instances of a particular sequence number are | d-CWs and MUST ensure that duplicate (replicated) instances of a | |||
| discarded. The specific mechanisms used for an implementation to | particular sequence number are discarded. The specific mechanisms | |||
| identify which received packets are duplicates and which are new is | used for an implementation to identify which received packets are | |||
| an implementation choice. Note that per Section 4.2.1 the sequence | duplicates and which are new is an implementation choice. Note that | |||
| number field length may be 16 or 28 bits, and the field value can | per Section 4.2.1 the sequence number field length may be 16 or 28 | |||
| wrap. | bits, and the field value can wrap. PEF MUST NOT be used with DetNet | |||
| flows configured with a d-CW sequence number field length of 0 bits. | ||||
| Note that an implementation MAY wish to constrain the maximum number | Note that an implementation MAY wish to constrain the maximum number | |||
| sequence numbers that are tracked, on platform-wide or per flow | sequence numbers that are tracked, on platform-wide or per flow | |||
| basis. Some implementations MAY support the provisioning of the | basis. Some implementations MAY support the provisioning of the | |||
| maximum number sequence numbers that are tracked number on either a | maximum number sequence numbers that are tracked number on either a | |||
| platform-wide or per flow basis. | platform-wide or per flow basis. | |||
| 4.2.2.2. Packet Ordering Function Processing | 4.2.2.3. Packet Ordering Function Processing | |||
| A function that is related to in-order delivery is the Packet | A function that is related to in-order delivery is the Packet | |||
| Ordering Function (POF). Implementations MAY support POF. When | Ordering Function (POF). Implementations MAY support POF. When | |||
| supported, use of the POF for a particular app-flow MUST be | supported, use of the POF for a particular DetNet service MUST be | |||
| provisioned via configuration, e.g., via the controller plane | provisioned via configuration, e.g., via the controller plane | |||
| described by [I-D.ietf-detnet-data-plane-framework]. Implementations | described by [I-D.ietf-detnet-data-plane-framework]. Implementations | |||
| MAY required that PEF and POF be used in combination. There is no | MAY required that PEF and POF be used in combination. There is no | |||
| requirement related to the order of execution of the Packet | requirement related to the order of execution of the Packet | |||
| Elimination and Ordering Functions in an implementation. | Elimination and Ordering Functions in an implementation. | |||
| After an app-flow is identified for a received DetNet MPLS packet, as | After a DetNet service is identified for a received DetNet MPLS | |||
| described above, an implementation MUST check if POF is configured | packet, as described above, an implementation MUST check if POF is | |||
| for that app-flow. When configured, the implementation MUST track | configured for that DetNet service. When configured, the | |||
| the sequence number contained in received d-CWs and MUST ensure that | implementation MUST track the sequence number contained in received | |||
| packets are processed in the order indicated in the received d-CW | d-CWs and MUST ensure that packets are processed in the order | |||
| sequence number field, which may not be in the order the packets are | indicated in the received d-CW sequence number field, which may not | |||
| received. As defined in Section 4.2.1 the sequence number field | be in the order the packets are received. As defined in | |||
| length may be 16 or 28 bits, is incremented by one (1) for each new | Section 4.2.1 the sequence number field length may be 16 or 28 bits, | |||
| app-flow packet sent, and the field value can wrap. The specific | is incremented by one (1) for each new MPLS packet sent for a | |||
| mechanisms used for an implementation to identify the order of | particular DetNet service, and the field value can wrap. The | |||
| received packets is an implementation choice. | specific mechanisms used for an implementation to identify the order | |||
| of received packets is an implementation choice. | ||||
| Note that an implementation MAY wish to constrain the maximum number | Note that an implementation MAY wish to constrain the maximum number | |||
| of out of order packets that can be processed, on platform-wide or | of out of order packets that can be processed, on platform-wide or | |||
| per flow basis. Some implementations MAY support the provisioning of | per flow basis. Some implementations MAY support the provisioning of | |||
| this number on either a platform-wide or per flow basis. The number | this number on either a platform-wide or per flow basis. The number | |||
| of out of order packets that can be processed also impacts the | of out of order packets that can be processed also impacts the | |||
| latency of a flow. | latency of a flow. | |||
| 4.2.3. F-Labels | 4.2.3. F-Labels | |||
| F-Labels are supported the DetNet forwarding sub-layer. F-Labels are | F-Labels are supported the DetNet forwarding sub-layer. F-Labels are | |||
| used to provide LSP-based connectivity between DetNet service sub- | used to provide LSP-based connectivity between DetNet service sub- | |||
| layer processing nodes. | layer processing nodes. | |||
| 4.2.3.1. Service Sub-Layer and Packet Replication Function Processing | 4.2.3.1. Service Sub-Layer Related Processing | |||
| DetNet MPLS end systems, edge nodes and relay nodes may operate at | DetNet MPLS end systems, edge nodes and relay nodes may operate at | |||
| the DetNet service sub-layer with understand of app-flows and their | the DetNet service sub-layer with understanding of DetNet services | |||
| requirements. As mentioned earlier, when operating at this layer | and their requirements. As mentioned earlier, when operating at this | |||
| such nodes can push, pop or swap (pop then push) S-Labels. In all | layer such nodes can push, pop or swap (pop then push) S-Labels. In | |||
| cases, the F-Labels used for the app-flow are always replaced and the | all cases, the F-Label(s) used for a DetNet service are always | |||
| following procedures apply. | replaced and the following procedures apply. | |||
| When sending a DetNet flow, zero or more F-Labels MAY be pushed on | When sending a DetNet flow, zero or more F-Labels MAY be pushed on | |||
| top of an S-Label by the node pushing an S-Label. The F-Labels to be | top of an S-Label by the node pushing an S-Label. The F-Label(s) to | |||
| pushed when sending a particular app-flow MUST be provisioned per | be pushed when sending a particular DetNet service MUST be | |||
| app-flow via configuration, e.g., via the controller plane discussed | provisioned per DetNet service via configuration, e.g., via the | |||
| in [I-D.ietf-detnet-data-plane-framework]. F-Labels can also provide | controller plane discussed in [I-D.ietf-detnet-data-plane-framework]. | |||
| context for an S-Label. To allow for the omission of F-Labels, an | F-Label(s) can also provide context for an S-Label. To allow for the | |||
| implementation SHOULD also allow an outgoing interface to be used. | omission of F-Label(s), an implementation SHOULD also allow an | |||
| outgoing interface to be configured. | ||||
| The Packet Replication Function (PRF) function MAY be supported by an | When PRF is supported, the same app-flow data will be sent over | |||
| implementation for outgoing DetNet flows. When replication is | multiple outgoing DetNet member flows using forwarding sub-layer | |||
| supported, the same app-flow data will be sent over multiple outgoing | LSPs. To support PRF an implementation MUST support the setting of | |||
| forwarding sub-layer LSPs. To support PRF an implementation MUST | different sets of F-Labels per DetNet member flow. To allow for the | |||
| support the setting of different sets of F-Labels. To allow for the | ||||
| omission of F-Labels, an implementation SHOULD also allow multiple | omission of F-Labels, an implementation SHOULD also allow multiple | |||
| outgoing interfaces to be provisioned. PRF MUST NOT be used with | outgoing interfaces to be provisioned. | |||
| app-flows configured with a d-CW sequence number field length of 0 | ||||
| bits. | ||||
| When a single set of F-Labels is provisioned for a particular | When a single set of F-Labels is provisioned for a particular | |||
| outgoing app-flow, that set of F-labels MUST be pushed after the | outgoing S-Label, that set of F-labels MUST be pushed after the | |||
| S-Label is pushed. The outgoing packet is then forwarded as | S-Label is pushed. The outgoing packet is then forwarded as | |||
| described below in Section 4.2.3.2. When a single outgoing interface | described below in Section 4.2.3.2. When a single outgoing interface | |||
| is provisioned, the outgoing packet is then forwarded as described | is provisioned, the outgoing packet is then forwarded as described | |||
| below in Section 4.2.3.2. | below in Section 4.2.3.2. | |||
| When multiple sets of F-Labels or interfaces are provisioned for a | When multiple sets of outgoing F-Labels or interfaces are provisioned | |||
| particular outgoing app-flow, a copy of the outgoing packet, | for a particular DetNet service, a copy of the outgoing packet, | |||
| including the pushed S-Label, MUST be made per F-label set and | including the pushed S-Label, MUST be made per F-label set and | |||
| outgoing interface. Each set of provisioned F-Labels are then pushed | outgoing interface. Each set of provisioned F-Labels are then pushed | |||
| onto a copy of the packet. Each copy is then forwarded as described | onto a copy of the packet. Each copy is then forwarded as described | |||
| below in Section 4.2.3.2. | below in Section 4.2.3.2. | |||
| As described in the previous section, when receiving a DetNet MPLS | As described in the previous section, when receiving a DetNet MPLS | |||
| flow, an implementation identifies the app-flow associated with the | flow, an implementation identifies the DetNet service associated with | |||
| incoming packet based on the S-Label. When a node is using platform | the incoming packet based on the S-Label. When a node is using | |||
| labels for S-Labels, any F-Labels can be popped and the S-label | platform labels for S-Labels, any F-Labels can be popped and the | |||
| uniquely identifies the app-flow. In the case where platform labels | S-label uniquely identifies the DetNet service. In the case where | |||
| are not used, F-Label(s) and, optionally, the incoming interface MUST | platform labels are not used, incoming F-Label(s) and, optionally, | |||
| also be provisioned for incoming app-flows. The provisioned | the incoming interface MUST also be provisioned for a DetNet service. | |||
| information MUST then be used to identify incoming app-flows based on | ||||
| the combination of S-Label and F-Label(s) or incoming interface. | ||||
| 4.2.3.2. Common F-Label Processing | 4.2.3.2. Common F-Label Processing | |||
| All DetNet aware MPLS nodes process F-Labels as needed to meet the | All DetNet aware MPLS nodes process F-Labels as needed to meet the | |||
| service requirements of the DetNet flow or flows carried in the LSPs | service requirements of the DetNet flow or flows carried in the LSPs | |||
| represented by the F-Labels. This includes normal push, pop and swap | represented by the F-Labels. This includes normal push, pop and swap | |||
| operations. Such processing is essentially the same type of | operations. Such processing is essentially the same type of | |||
| processing provided for TE LSPs, although the specific service | processing provided for TE LSPs, although the specific service | |||
| parameters, or traffic specification, can differ. When the DetNet | parameters, or traffic specification, can differ. When the DetNet | |||
| service parameters of the app-flow or flows carried in an LSP | service parameters of the DetNet flow or flows carried in an LSP | |||
| represented by an F-Label can be met by an exiting TE mechanism, the | represented by an F-Label can be met by an existing TE mechanism, the | |||
| forwarding sub-layer processing node MAY be a DetNet unaware, i.e., | forwarding sub-layer processing node MAY be a DetNet unaware, i.e., | |||
| standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service | standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service | |||
| as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], | as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], | |||
| [RFC3473], [RFC4875], [RFC5440], and [RFC8306]. | [RFC3473], [RFC4875], [RFC5440], and [RFC8306]. | |||
| More specifically, as mentioned above, the DetNet forwarding sub- | More specifically, as mentioned above, the DetNet forwarding sub- | |||
| layer provides explicit routes and allocated resources, and F-Labels | layer provides explicit routes and allocated resources, and F-Labels | |||
| are used to map to each. Explicit routes are supported based on the | are used to map to each. Explicit routes are supported based on the | |||
| topmost (outermost) F-Label that is pushed or swapped and the LSP | topmost (outermost) F-Label that is pushed or swapped and the LSP | |||
| that corresponds to this label. This topmost (outgoing) label MUST | that corresponds to this label. This topmost (outgoing) label MUST | |||
| skipping to change at page 17, line 4 ¶ | skipping to change at page 17, line 17 ¶ | |||
| 4.3. OAM Indication | 4.3. OAM Indication | |||
| OAM follows the procedures set out in [RFC5085] with the restriction | OAM follows the procedures set out in [RFC5085] with the restriction | |||
| that only Virtual Circuit Connectivity Verification (VCCV) type 1 is | that only Virtual Circuit Connectivity Verification (VCCV) type 1 is | |||
| supported. | supported. | |||
| As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW | As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW | |||
| is 0x0 the payload following the d-CW is normal user data. However, | is 0x0 the payload following the d-CW is normal user data. However, | |||
| when the first nibble of the d-CW is 0X1, the payload that follows | when the first nibble of the d-CW is 0X1, the payload that follows | |||
| the d-DW is an OAM payload with the OAM type indicated by the value | the d-CW is an OAM payload with the OAM type indicated by the value | |||
| in the d-CW Channel Type field. | in the d-CW Channel Type field. | |||
| The reader is referred to [RFC5085] for a more detailed description | The reader is referred to [RFC5085] for a more detailed description | |||
| of the Associated Channel mechanism, and to the DetNet work on OAM | of the Associated Channel mechanism, and to the DetNet work on OAM | |||
| for more information DetNet OAM. | for more information DetNet OAM. | |||
| Additional considerations on DetNet-specific OAM are subjects for | Additional considerations on DetNet-specific OAM are subjects for | |||
| further study. | further study. | |||
| 4.4. Flow Aggregation | 4.4. Flow Aggregation | |||
| skipping to change at page 18, line 44 ¶ | skipping to change at page 19, line 5 ¶ | |||
| Both the aggregation label, which is referred to as an A-Label, and | Both the aggregation label, which is referred to as an A-Label, and | |||
| the individual flow's S-Label have their MPLS S bit set indicating | the individual flow's S-Label have their MPLS S bit set indicating | |||
| bottom of stack, and the d-CW allows the PREOF to work. An A-Label | bottom of stack, and the d-CW allows the PREOF to work. An A-Label | |||
| is a special case of an S-Label, whose properties are known only at | is a special case of an S-Label, whose properties are known only at | |||
| the aggregation and deaggregation end-points. | the aggregation and deaggregation end-points. | |||
| It is a property of the A-Label that what follows is a d-CW followed | It is a property of the A-Label that what follows is a d-CW followed | |||
| by an MPLS label stack. A relay node processing the A-Label would | by an MPLS label stack. A relay node processing the A-Label would | |||
| not know the underlying payload type, and the A-Label would be | not know the underlying payload type, and the A-Label would be | |||
| process as a normal S-Label. This would only be known to a node that | processed as a normal S-Label. This would only be known to a node | |||
| was a peer of the node imposing the S-Label. However there is no | that was a peer of the node imposing the S-Label. However there is | |||
| real need for it to know the payload type during aggregation | no real need for it to know the payload type during aggregation | |||
| processing. | processing. | |||
| As in the previous section, nodes supporting this type of aggregation | As in the previous section, nodes supporting this type of aggregation | |||
| will need to ensure that individual and aggregated flows receive the | will need to ensure that individual and aggregated flows receive the | |||
| traffic treatment required to ensure the required DetNet service is | traffic treatment required to ensure the required DetNet service is | |||
| preserved. Also, it is the controller plane's responsibility to to | preserved. Also, it is the controller plane's responsibility to to | |||
| ensure that the service required on the aggregate flow are properly | ensure that the service required on the aggregate flow are properly | |||
| provisioned. | provisioned. | |||
| 4.5. Service Sub-Layer Considerations | 4.5. Service Sub-Layer Considerations | |||
| skipping to change at page 19, line 25 ¶ | skipping to change at page 19, line 35 ¶ | |||
| receive such packets the replication function would make the loop | receive such packets the replication function would make the loop | |||
| more destructive of bandwidth than a conventional unicast loop. | more destructive of bandwidth than a conventional unicast loop. | |||
| Ultimately the TTL in the S-Label will cause the packet to die during | Ultimately the TTL in the S-Label will cause the packet to die during | |||
| a transient loop, but given the sensitivity of applications to packet | a transient loop, but given the sensitivity of applications to packet | |||
| latency the impact on the DetNet application would be severe. To | latency the impact on the DetNet application would be severe. To | |||
| avoid the problem of a transient forwarding loop, changes to an LSP | avoid the problem of a transient forwarding loop, changes to an LSP | |||
| supporting DetNet MUST be loop-free. | supporting DetNet MUST be loop-free. | |||
| 4.5.1. Edge Node Processing | 4.5.1. Edge Node Processing | |||
| An edge node is responsible for matching ingress packets to the | A DetNet Edge node operates in the DetNet forwarding sub-layer and | |||
| service they require and encapsulating them accordingly. An edge | service sub-layer. An edge node is responsible for matching incoming | |||
| node may participate in the packet replication and duplicate packet | packets to the service they require and encapsulating them | |||
| elimination. | accordingly. An edge node may perform PRF, PEF, and or POF. Details | |||
| on encapsulation can be found in Section 4.2; details on PRF can be | ||||
| The DetNet-aware forwarder selects the egress DetNet member flow | found in Section 4.2.2.1; details on PEF can be found in | |||
| segment based on the flow identification. The mapping of ingress | Section 4.2.2.2; and details on POF can be found in Section 4.2.2.3. | |||
| DetNet member flow segment to egress DetNet member flow segment may | ||||
| be statically or dynamically configured. Additionally the DetNet- | ||||
| aware forwarder does duplicate frame elimination based on the flow | ||||
| identification and the sequence number combination. The packet | ||||
| replication is also done within the DetNet-aware forwarder. | ||||
| 4.5.2. Relay Node Processing | 4.5.2. Relay Node Processing | |||
| A DetNet Relay node operates in the DetNet forwarding sub-layer and | A DetNet Relay node operates in the DetNet forwarding sub-layer and | |||
| service sub-layer. For DetNet using MPLS forwarding related | service sub-layer. For DetNet using MPLS forwarding related | |||
| processing is performed on the F-Label. This processing is done | processing is performed on the F-Label. This processing is done | |||
| within an extended forwarder function. Whether an ingress DetNet | within an extended forwarder function. Whether an incoming DetNet | |||
| member flow receives DetNet specific processing depends on how the | flow receives DetNet specific processing depends on how the | |||
| forwarding is programmed. Some relay nodes may be DetNet service | forwarding is programmed. Some relay nodes may be DetNet service | |||
| aware for certain DetNet services, while for other DetNet services | aware for certain DetNet services, while for other DetNet services | |||
| these nodes may perform as unmodified LSRs that only understand how | these nodes may perform as unmodified LSRs that only understand how | |||
| to switch MPLS-TE LSPs, i.e., as a transit nodes, see Section 4.4. | to switch MPLS-TE LSPs, i.e., as a transit node, see Section 4.4. | |||
| Again, this is entirely up to how the forwarding has been programmed. | Again, this is entirely up to how the forwarding has been programmed. | |||
| During the elimination and replication process the sequence number of | During the elimination and replication process the sequence number of | |||
| the ingress DetNet member flow MUST be preserved and copied to the | an incoming DetNet packet MUST be preserved and carried in the | |||
| corresponding egress DetNet member flow. Specifically, a relay node | corresponding outgoing DetNet packet. For example, a relay node that | |||
| sends the same sequence number in an outgoing packet of a DetNet | performs both PEF and PRF first performs PEF on incoming packets to | |||
| member flow that is received in the corresponding incoming packet of | create a compound flow. It then performs PRF and copies the app-flow | |||
| a DetNet compound flow. This is true whether or not PREOF is | data and the d-CW into packets for each outgoing DetNet member flow. | |||
| performed at the relay node. | ||||
| The internal design of a relay node is out of scope of this document. | The internal design of a relay node is out of scope of this document. | |||
| However the reader's attention is drawn to the need to make any PREOF | However the reader's attention is drawn to the need to make any PREOF | |||
| state available to the packet processor(s) dealing with packets to | state available to the packet processor(s) dealing with packets to | |||
| which the PREOF functions must be applied, and to maintain that state | which the PREOF functions must be applied, and to maintain that state | |||
| is such away that it is available to the packet processor operation | is such a way that it is available to the packet processor operation | |||
| on the next packet in the DetNet flow (which may be a duplicate, a | on the next packet in the DetNet flow (which may be a duplicate, a | |||
| late packet, or the next packet in sequence. | late packet, or the next packet in sequence). | |||
| 4.6. Forwarding Sub-Layer Considerations | 4.6. Forwarding Sub-Layer Considerations | |||
| 4.6.1. Class of Service | 4.6.1. Class of Service | |||
| Class and quality of service, i.e., CoS and QoS, are terms that are | Class and quality of service, i.e., CoS and QoS, are terms that are | |||
| often used interchangeably and confused with each other. In the | often used interchangeably and confused with each other. In the | |||
| context of DetNet, CoS is used to refer to mechanisms that provide | context of DetNet, CoS is used to refer to mechanisms that provide | |||
| traffic forwarding treatment based on aggregate group basis and QoS | traffic forwarding treatment based on aggregate group basis and QoS | |||
| is used to refer to mechanisms that provide traffic forwarding | is used to refer to mechanisms that provide traffic forwarding | |||
| skipping to change at page 22, line 8 ¶ | skipping to change at page 22, line 15 ¶ | |||
| both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., | both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., | |||
| and hybrid combinations of the two. The details of the controller | and hybrid combinations of the two. The details of the controller | |||
| plane solution required for the label distribution and the management | plane solution required for the label distribution and the management | |||
| of the label number space are out of scope of this document. There | of the label number space are out of scope of this document. There | |||
| are particular DetNet considerations and requirements that are | are particular DetNet considerations and requirements that are | |||
| discussed in [I-D.ietf-detnet-data-plane-framework]. | discussed in [I-D.ietf-detnet-data-plane-framework]. | |||
| 5.1. Service Sub-Layer Information Summary | 5.1. Service Sub-Layer Information Summary | |||
| The following summarizes the information that is needed on service | The following summarizes the information that is needed on service | |||
| sub-layer aware nodes that send DetNet MPLS traffic, on a per service | sub-layer aware nodes that transmit DetNet MPLS traffic, on a per | |||
| basis: | service basis: | |||
| o App-Flow identification information, e.g., an incoming service on | o App-Flow identification information, e.g., IP information as | |||
| a relay node or IP information as defined in | defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information | |||
| [I-D.ietf-detnet-ip-over-mpls]. | is not needed on DetNet relay nodes. | |||
| o The sequence number length to be used for the service. Valid | o The sequence number length to be used for the service. Valid | |||
| values included 0, 16 and 28 bits. 0 bits cannot be used when PRF | values included 0, 16 and 28 bits. 0 bits cannot be used when PEF | |||
| is configured for the service. | or POF is configured for the service. | |||
| o The S-Label for the service. | o The outgoing S-Label for the service. | |||
| o If PRF is to be provided for the service. | o If PRF is to be provided for the service. | |||
| o The forwarding sub-layer information associated with the output of | o The forwarding sub-layer information associated with the output of | |||
| the service sub-layer. Note that when the PRF function is | the service sub-layer. Note that when the PRF function is | |||
| provisioned, this information is per DetNet member flow. | provisioned, this information is per DetNet member flow. | |||
| Logically the forwarding sub-layer information is a pointer to | Logically the forwarding sub-layer information is a pointer to | |||
| further details of transmission of Detnet flows at the forwarding | further details of transmission of Detnet flows at the forwarding | |||
| sub-layer. | sub-layer. | |||
| The following summarizes the information that is needed on service | The following summarizes the information that is needed on service | |||
| sub-layer aware nodes that receives DetNet MPLS traffic, on a per | sub-layer aware nodes that receive DetNet MPLS traffic, on a per | |||
| service basis: | service basis: | |||
| o The forwarding sub-layer information associated with the input of | o The forwarding sub-layer information associated with the input of | |||
| the service sub-layer. Note that when the PEF function is | the service sub-layer. Note that when the PEF function is | |||
| provisioned, this information is per DetNet member flow. | provisioned, this information is per DetNet member flow. | |||
| Logically the forwarding sub-layer information is a pointer to | Logically the forwarding sub-layer information is a pointer to | |||
| further details of the reception of Detnet flows at the forwarding | further details of the reception of Detnet flows at the forwarding | |||
| sub-layer or A-Label. | sub-layer or A-Label. | |||
| o The S-Label for the received service. | o The incoming S-Label for the service. | |||
| o If PEF or POF is to be provided for the service. | o If PEF or POF is to be provided for the service. | |||
| o The sequence number length to be used for the service. Valid | o The sequence number length to be used for the service. Valid | |||
| values included 0, 16 and 28 bits. 0 bits cannot be used when PEF | values included 0, 16 and 28 bits. 0 bits cannot be used when PEF | |||
| or POF are configured for the service. | or POF are configured for the service. | |||
| o App-Flow identification information, e.g., IP information as | ||||
| defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information | ||||
| is not needed on DetNet relay nodes. | ||||
| 5.1.1. Service Aggregation Information Summary | 5.1.1. Service Aggregation Information Summary | |||
| Nodes performing aggregation using A-Labels, per | Nodes performing aggregation using A-Labels, per | |||
| Section Section 4.4.2, require the additional information summarized | Section Section 4.4.2, require the additional information summarized | |||
| in this section. | in this section. | |||
| The following summarizes the information that is needed on a node | The following summarizes the additional information that is needed on | |||
| that sends aggregated flows using A-Labels: | a node that sends aggregated flows using A-Labels: | |||
| o The S-Labels or F-Labels that are to be carried over each | o The S-Labels or F-Labels that are to be carried over each | |||
| aggregated service. | aggregated service. | |||
| o The A-Label associated with each aggregated service. | o The A-Label associated with each aggregated service. | |||
| o The other S-Label information summarized above. | o The other S-Label information summarized above. | |||
| On the receiving node, the A-Label provides the forwarding context of | On the receiving node, the A-Label provides the forwarding context of | |||
| an incoming interface or an F-Label and is used in subsequent service | an incoming interface or an F-Label and is used in subsequent service | |||
| skipping to change at page 25, line 21 ¶ | skipping to change at page 25, line 32 ¶ | |||
| domain. | domain. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document makes no IANA requests. | This document makes no IANA requests. | |||
| 8. Acknowledgements | 8. Acknowledgements | |||
| The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, | The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, | |||
| David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David | David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David | |||
| Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. | Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo | |||
| Bernardos for their various contributions to this work. | and Carlos J. Bernardos for their various contributions to this | |||
| work. | ||||
| 9. Contributors | 9. Contributors | |||
| RFC7322 limits the number of authors listed on the front page of a | RFC7322 limits the number of authors listed on the front page of a | |||
| draft to a maximum of 5. The editor wishes to thank and acknowledge | draft to a maximum of 5. The editor wishes to thank and acknowledge | |||
| the follow author for contributing text to this draft. | the follow author for contributing text to this draft. | |||
| Don Fedyk | Don Fedyk | |||
| LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
| Email: dfedyk@labn.net | Email: dfedyk@labn.net | |||
| skipping to change at page 27, line 32 ¶ | skipping to change at page 27, line 48 ¶ | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [I-D.ietf-detnet-data-plane-framework] | [I-D.ietf-detnet-data-plane-framework] | |||
| Varga, B., Farkas, J., Berger, L., Malis, A., and S. | Varga, B., Farkas, J., Berger, L., Malis, A., and S. | |||
| Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- | Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- | |||
| data-plane-framework-06 (work in progress), May 2020. | data-plane-framework-06 (work in progress), May 2020. | |||
| [I-D.ietf-detnet-ip] | [I-D.ietf-detnet-ip] | |||
| Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. | Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. | |||
| Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06 | Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 | |||
| (work in progress), April 2020. | (work in progress), July 2020. | |||
| [I-D.ietf-detnet-ip-over-mpls] | [I-D.ietf-detnet-ip-over-mpls] | |||
| Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. | Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. | |||
| Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- | Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- | |||
| detnet-ip-over-mpls-06 (work in progress), May 2020. | detnet-ip-over-mpls-06 (work in progress), May 2020. | |||
| [I-D.ietf-detnet-mpls-over-tsn] | [I-D.ietf-detnet-mpls-over-tsn] | |||
| Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet | Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet | |||
| Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking | Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking | |||
| (TSN)", draft-ietf-detnet-mpls-over-tsn-02 (work in | (TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in | |||
| progress), March 2020. | progress), June 2020. | |||
| [I-D.ietf-detnet-security] | [I-D.ietf-detnet-security] | |||
| Mizrahi, T. and E. Grossman, "Deterministic Networking | Mizrahi, T. and E. Grossman, "Deterministic Networking | |||
| (DetNet) Security Considerations", draft-ietf-detnet- | (DetNet) Security Considerations", draft-ietf-detnet- | |||
| security-10 (work in progress), May 2020. | security-10 (work in progress), May 2020. | |||
| [IEEE802.1AE-2018] | [IEEE802.1AE-2018] | |||
| IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC | IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC | |||
| Security (MACsec)", 2018, | Security (MACsec)", 2018, | |||
| <https://ieeexplore.ieee.org/document/8585421>. | <https://ieeexplore.ieee.org/document/8585421>. | |||
| End of changes. 58 change blocks. | ||||
| 183 lines changed or deleted | 199 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/ | ||||