Subject: [Detnet] Implementing the discussion at IETF 97 on architecture doc

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Mar 2017 18:01:54 +0000

Dear all:

During the detnet meeting at IETF 97 we discussed that some pieces of the service model presented by Balazs and Janos could effectively by added to the architecture, in particular the discussion on service points, models and flow identification.

So we worked together and came up with proposed additions as follows. We would like to publish this by the cutoff date next Monday so if there is an issue with the proposed change please let us discuss it by then.

The proposed additions are as follows:

Adding Janos and Balazs as co-authors, then:

1) adding a section  on the reference model:

     4.1.  DetNet systems  . . . . . . . . . . . . . . . . . . . . .  12

       4.1.1.  Network reference model . . . . . . . . . . . . . . .  13

       4.1.2.  End system  . . . . . . . . . . . . . . . . . . . . .  14

2) more on detnet flows:

      4.3.1.  DetNet flow types . . . . . . . . . . . . . . . . . .  18

  And replacing:

     4.7.  Exporting flow identification . . . . . . . . . . . . . .  20

We now propose:

     4.9.  Flow identification at technology borders . . . . . . . .  26

       4.9.1.  Exporting flow identification . . . . . . . . . . . .  26

       4.9.2.  Flow attribute mapping between layers . . . . . . . .  27

       4.9.3.  Flow-ID mapping examples  . . . . . . . . . . . . . .  29

3) more on

4.5.  Service instance  . . . . . . . . . . . . . . . . . . . .  21

The changes include this new description of the DetNet Service Reference Model (multi-domain)

DetNet                                                            DetNet

end system                                                        end system

   _                                                                    _

  / \       +----DetNet-UNI (U)                                        / \

/App\      |                                                         /App\

/-----\     |                                                        /-----\

| NIC |     v         ________                                       | NIC |

+--+--+     _____    /        \                 DetNet-UNI (U) --+   +--+--+

   |       /     \__/          \                                 |      |

   |      / +----+    +----+    \_____                           |      |

   |     /  |    |    |    |          \_______                   |      |

   +--------U PE +----+ P  +----+             \              _   v      |

         |  |    |    |    |    |              |         ___/ \         |

         |  +--+-+    +----+    |       +----+ |        /      \_       |

         \     |                |       |    | |       /         \      |

          \    |   +----+    +--+-+  +--+PE  |----------         U------+

           \   |   |    |    |    |  |  |    | |       \_      _/

            \  +---+ P  +----+ P  +--+  +----+ |         \____/

             \___  |    |    |    |           /

                 \ +----+__  +----+     DetNet-1        DetNet-2

   |              \_____/  \___________/                                |

   |                                                                    |

   |        |     End-to-End-Service         |         |         |      |

   <-------------------------------------------------------------------->

   |        |     DetNet-Service             |         |         |      |

   |        <---------------------------------------------------->      |

   |        |                                |         |         |      |

And text to cover it that provides details on the UNI

   The figure above shows the DetNet service related reference points

   and main components (Figure 2).

   DetNet-UNIs ("U" in Figure 2) are assumed in this document to be

   packet-based reference points and provide connectivity over the

   packet network.  A DetNet-UNI may provide multiple functions, e.g.,

   it may add networking technology specific encapsulation to the DetNet

   flows if necessary; it may provide status of the availability of the

   connection associated to a reservation; it may provide a

   synchronization service for the end system; it may carry enough

   signaling to place the reservation in a network without a controller,

   or if the controller only deals with the network but not the end

   points.  Internal reference points of end systems (between the

   application and the NIC) are more challenging from control

   perspective and they may have extra requirements (e.g., in-order

   delivery is expected in end system internal reference points, whereas

   it is considered optional over the DetNet-UNI), therefore not covered

   in this document.

New text also detail what an end system is

  The native data flow between the source/destination end systems is

   referred to as application-flow (App-flow).  The traffic

   characteristics of an App-flow can be CBR (constant bit rate) or VBR

   (variable bit rate) and can have L1 or L2 or L3 encapsulation (e.g.,

   TDM (time-division multiplexing), Ethernet, IP).  These

   characteristics are considered as input for resource reservation and

   might be simplified to ensure determinism during transport (e.g.,

   making reservations for the peak rate of VBR traffic, etc.).

   An end system may or may not be DetNet transport layer aware or

   DetNet service layer aware.  That is, an end system may or may not

   contain DetNet specific functionality.  End systems with DetNet

   functionalities may have the same or different transport layer as the

   connected DetNet domain.  Grouping of end systems are shown in

   Figure 3.

                End system

                    |

                    |

                    |  DetNet aware ?

                   / \

           +------<   >------+

        NO |       \ /       | YES

           |        v        |

    DetNet unaware           |

      End system             |

                             | Service/

                             | Transport

                            / \  aware ?

                  +--------<   >-------------+

          t-aware |         \ /              | s-aware

                  |          v               |

                  |          | both          |

                  |          |               |

          DetNet t-aware     |        DetNet s-aware

            End system       |         End system

                             v

                       DetNet st-aware

                         End system

                     Figure 3: Grouping of end systems

A new discussion on flow types reads as follows:

4.3.1.  DetNet flow types

   A DetNet flow can have different formats during while it is

   transported between the peer end systems.  Therefore, the following

   possible types / formats of a DetNet flow are distinguished in this

   document:

   o  App-flow: native format of a DetNet flow.  It does not contain any

      DetNet related attributes.

   o  DetNet-t-flow: specific format of a DetNet flow.  Only requires

      the congestion / latency features provided by the Detnet transport

      layer.

   o  DetNet-s-flow: specific format of a DetNet flow.  Only requires

      the replication/elimination feature ensured by the DetNet service

      layer.

   o  DetNet-st-flow: specific format of a DetNet flow.  It requires

      both DetNet Service and Transport layer functions during

      forwarding.

Finally we propose to update the flow discussion as follows:

4.9.  Flow identification at technology borders

4.9.1.  Exporting flow identification

<..>

4.9.2.  Flow attribute mapping between layers

   Transport of DetNet flows over multiple technology domains may

   require that lower layers are aware of specific flows of higher

   layers.  Such an "exporting of flow identification" is needed each

   time when the forwarding paradigm is changed on the transport path

   (e.g., two LSRs are interconnected by a L2 bridged domain, etc.).

   The three main forwarding methods considered for deterministic

   networking are:

   o  IP routing

   o  MPLS label switching

   o  Ethernet bridging

   The simplest solution for generalized flow identification could be to

   define a unique Flow-ID triplet per DetNet flow (e.g., [IP: "IPv6-

   flow-label"+"IPv6-address"; MPLS: "PW-label"+"LSP-label"; Ethernet:

   "VLAN-ID"+"MAC-address").  This triplet can be used by the DetNet

   encoding function of technology border nodes (where forwarding

   paradigm changes) to adapt to capabilities of the next hop node.  It

   means that a packet may contain multiple (forwarding paradigm

   specific) Flow-IDs during its transport.  Technology border nodes may

   add / remove a (forwarding paradigm specific) Flow-ID.

   [Note: Seq-num attribute may require a similar functionality at

   technology border nodes.]

         add/remove     add/remove

         Eth Flow-ID    IP Flow-ID

             |             |

             v             v

          +-----------------------------------------------------------+

          |      |      |      |                                      |

          | Eth  | MPLS |  IP  |     Application data                 |

          |      |      |      |                                      |

          +-----------------------------------------------------------+

                    ^

                    |

                add/remove

               MPLS Flow-ID

                  Figure 7: Packet with multiple Flow-IDs

   The additional (domain specific) Flow-ID can be

   o  created by a domain specific function or

   o  derived from the Flow-ID added to the App-flow,

   so that it must be unique inside the given domain.  Note, that the

   Flow-ID added to the App-flow is still present in the packet, but

   transport nodes may lack the function to recognize it; that's why the

   additional Flow-ID is added (pushed).

4.9.3.  Flow-ID mapping examples

   IP nodes and MPLS nodes are assumed to be configured to push such an

   additional (domain specific) Flow-ID when sending traffic to an

   Ethernet switch (as shown in the examples below).

   Figure 8 shows a scenario where an IP end system ("IP-A") is

   connected via two Ethernet switches ("ETH-n") to an IP router ("IP-

   1").

                                     IP domain

                  <-----------------------------------------------

           +======+                                       +======+

           |L3-ID |                                       |L3-ID |

           +======+  /\                           +-----+ +======+

                    /  \       Forward as         |     |

                   /IP-A\      per ETH-ID         |IP-1 |      Recognize

   Push  ------>  +-+----+         |              +---+-+  <----- ETH-ID

   ETH-ID           |         +----+-----+            |

                    |         v          v            |

                    |      +-----+    +-----+         |

                    +------+     |    |     +---------+

           +......+        |ETH-1+----+ETH-2|           +======+

           .L3-ID .        +-----+    +-----+           |L3-ID |

           +======+             +......+                +======+

           |ETH-ID|             .L3-ID .                |ETH-ID|

           +======+             +======+                +------+

                                |ETH-ID|

                                +======+

                             Ethernet domain

                           <---------------->

          Figure 8: IP nodes interconnected by an Ethernet domain

   End system "IP-A" uses the original App-flow specific ID ("L3-ID"),

   but as it is connected to an Ethernet domain it has to push an

   Ethernet-domain specific flow-ID ("VID + multicast MAC address",

   referred as "ETH-ID") before sending the packet to "ETH-1" node.

   Ethernet switch "ETH-1" can recognize the data flow based on the

   "ETH-ID" and it does forwarding toward "ETH-2".  "ETH-2" switches the

   packet toward the IP router.  "IP-1" must be configured to receive

   the Ethernet Flow-ID specific multicast stream, but (as it is an L3

   node) it decodes the data flow ID based on the "L3-ID" fields of the

   received packet.

   Figure 9 shows a scenario where MPLS domain nodes ("PE-n" and "P-m")

   are connected via two Ethernet switches ("ETH-n").

                                    MPLS domain

                  <----------------------------------------------->

       +=======+                                  +=======+

       |MPLS-ID|                                  |MPLS-ID|

       +=======+  +-----+                 +-----+ +=======+ +-----+

                  |     |   Forward as    |     |           |     |

                  |PE-1 |   per ETH-ID    | P-2 +-----------+ PE-2|

   Push   ----->  +-+---+        |        +---+-+           +-----+

   ETH-ID           |      +-----+----+       |  \ Recognize

                    |      v          v       |   +-- ETH-ID

                    |   +-----+    +-----+    |

                    +---+     |    |     +----+

           +.......+    |ETH-1+----+ETH-2|   +=======+

           .MPLS-ID.    +-----+    +-----+   |MPLS-ID|

           +=======+                         +=======+

           |ETH-ID |         +.......+       |ETH-ID |

           +=======+         .MPLS-ID.       +-------+

                             +=======+

                             |ETH-ID |

                             +=======+

                          Ethernet domain

                        <---------------->

         Figure 9: MPLS nodes interconnected by an Ethernet domain

   "PE-1" uses the MPLS specific ID ("MPLS-ID"), but as it is connected

   to an Ethernet domain it has to push an Ethernet-domain specific

   flow-ID ("VID + multicast MAC address", referred as "ETH-ID") before

   sending the packet to "ETH-1".  Ethernet switch "ETH-1" can recognize

   the data flow based on the "ETH-ID" and it does forwarding toward

   "ETH-2".  "ETH-2" switches the packet toward the MPLS node ("P-2").

   "P-2" must be configured to receive the Ethernet Flow-ID specific

   multicast stream, but (as it is an MPLS node) it decodes the data

   flow ID based on the "MPLS-ID" fields of the received packet.

What do you think?

Pascal and Norm

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 8 Mar 2017 12:36:44 -0800

Hi,

[snip]

>    flow-label"+"IPv6-address"; MPLS: "PW-label"+"LSP-label"; Ethernet:

The discussion on this part has not yet completed in DP design team. I 
am a bit worried writing this specific part down before we actually know 
how we are going to implement on the data plane. The above is not, as 
far as I understand, aligned with the DT progress. To get around the 
chicken-egg thing here either defer documenting for now or emphasize 
more that the above is an example.

- Jouni

>    add / remove a (forwarding paradigm specific) Flow-ID.

[snap]

> What do you think?
>
>
>
> Pascal and Norm
>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Mar 2017 08:06:57 +0000

I agree, Jouni, 

we seem to be placing the horses before the cart.
Let us comment out that text for now.

Take care,

Pascal

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: mercredi 8 mars 2017 21:37
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] Implementing the discussion at IETF 97 on architecture doc

Hi,

[snip]

>    flow-label"+"IPv6-address"; MPLS: "PW-label"+"LSP-label"; Ethernet:

The discussion on this part has not yet completed in DP design team. I am a bit worried writing this specific part down before we actually know how we are going to implement on the data plane. The above is not, as far as I understand, aligned with the DT progress. To get around the chicken-egg thing here either defer documenting for now or emphasize more that the above is an example.

- Jouni

[snap]

---

From: Lou Berger <[email-masked]>
Date: Thu, 9 Mar 2017 09:12:31 -0500

Pascal,

    Another thing to consider bringing into the Architecture document
are some of the diagrams and related text from Section 3 of
draft-ietf-detnet-dp-alt.  I think the whole section, with the exception
of the last two paragraphs on page 5, is good text to bring over.  

Lou
(as contributor, co-author of dp-alt)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Mar 2017 16:11:38 +0000

Hello Lou:

Did  section 3 evolve since the publication in September? Will there be an 01 of the dp alt draft before cutoff Monday?

Take care,

Pascal

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: jeudi 9 mars 2017 15:13
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] Implementing the discussion at IETF 97 on architecture doc

Pascal,

    Another thing to consider bringing into the Architecture document are some of the diagrams and related text from Section 3 of 	.  I think the whole section, with the exception of the last two paragraphs on page 5, is good text to bring over.  

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 9 Mar 2017 11:23:34 -0500

On 3/9/2017 11:11 AM, Pascal Thubert (pthubert) wrote:
> Hello Lou:
>
> Did  section 3 evolve since the publication in September? 
Not that I know of - but Jouni would know for sure.

> Will there be an 01 of the dp alt draft before cutoff Monday?
I don't expect on.

Lou

PS for source, see
https://github.com/jounikor/draft-dt-detnet-dp-alt/blob/master/draft-ietf-detnet-dp-alt-00.xml

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 9 Mar 2017 10:38:39 -0800

> Not that I know of - but Jouni would know for sure.

Nope.

>> Will there be an 01 of the dp alt draft before cutoff Monday?

and nope. i do intend to finish the -alt draft but not for the next meeting.

- Jouni

---

From: gengxuesong <[email-masked]>
Date: Fri, 10 Mar 2017 08:52:06 +0000

Hi Jouni,

Recently, the relationship between DetNet Service Model and data plane design is being discussed in the mailing list. To make it clear, I have reviewed the related discussion before and make a simple summary：

In IETF 94th, “DetNet Data Plane using PseudoWires” gives a basic idea of the classification of the service model (although the word “service model” is not mentioned in the slides): 
1.	Ethernet over MPLS for 802.1CB packets
2.	Ethernet over MPLS for non-802.1CB Ethernet packets
3.	Packet PW encapsulation over an MPLS PSN for IP packets
The data plane solution of 1 is different from 2 and 3

In IETF 97th, “DetNet Data Plane Discussion” gives four types of service models:
1.	DetNet End-to-end
2.	TSN interconnect, connecting two L2 TSN islands
3.	Service translation, from L2 TSN to DetNet and vice versa
4.	Service interworking ,connecting TSN end systems to DetNet end systems
And the data plane solution of these four cases are different from each other.

In IETF 97th, “DetNet Service Model” gives service models based on three types of the flows:
1.	App-flow: native format of a DetNet flow. It does not contain any DetNet related attributes
2.	DetNet-s-flow: specific format of a DetNet flow.  It is an App-flow extended with some DetNet service related attributes (i.e., Flow-ID and/or Seq-num).
3.	DetNet-st-flow: specific format of a DetNet flow.  It is an App-flow extended with both DetNet service layer and DetNet transport layer attributes, i.e., encapsulated according to the forwarding paradigm of the DetNet domain.

So I am confused whether we have already got to a conclusion about the service model classification, especially the influence it may have on the data plane.

If not, I think we should get to some degree of agreement about the service model before data plane design, or the data plane may not comfort to the DetNet service model in the current draft.

Emma

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Friday, March 10, 2017 2:39 AM
To: Lou Berger; Pascal Thubert (pthubert); [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] Implementing the discussion at IETF 97 on architecture doc

Nope.

- Jouni

>> To: Pascal Thubert (pthubert) <[email-masked]>; 
>> [email-masked]; [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Mar 2017 18:41:32 +0000

Hello Lou:

None of us could do the merge properly before cut off so I published what we did so far and we'll work on putting things together with the DT draft as soon as possible.

Take care,

Pascal

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: jeudi 9 mars 2017 15:13
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Detnet] Implementing the discussion at IETF 97 on architecture doc

Pascal,

    Another thing to consider bringing into the Architecture document are some of the diagrams and related text from Section 3 of draft-ietf-detnet-dp-alt.  I think the whole section, with the exception of the last two paragraphs on page 5, is good text to bring over.  

Lou