[Detnet-dp-dt] quick notes from 1/24/17 call

[Jouni Korhonen <[e-mail]>]

Folks,

We had a +1h call last night. Participants: Jouni, Carlos, Loa, Norm, Yuanlong, Janos and Tal.

For the discussion refer to Loa’s slides sent to the DT list on 1/13/17.

We seemed to have reached consensus on PWs and three label approach i.e., transport label + PW label + “detnet PW” label (d-pw in slides and this one is associated with the seqnum). The “detnet PW” label is end to end between detnet flow end points and unique within the detnet domain. This arrangement will cause 16 octet overhead (3x label + cw):

+-----------------+
| Transport Label | --> per each LSR; top of stack
+-----------------+
| PW Label        | --> per each PW (between T-PEs and/or S-PEs)
+-----------------+
| Detnet PW Label | --> between DetNet end points
+-----------------+
| CW - 28 bit sn  | --> associated with DetNet PW label 
+-----------------+
| Payload         | --> whatever we transport
+-----------------+

Multiplexing: one transport label may transport PW labels, and one PW label may transport multiple “detnet PW” labels.

The (virtual) network topology (LSP paths) can be programmed at the PW level. This means any detnet flow can use those without having to setup path individually for each “detnet PW”. As a consequence adding new detnet flows to system is enable i.e., when the duplicate detection and elimination function sees a new “detnet PW” label, it can instantiate new function to deal with duplicate detection and elimination - dynamically. 

We started the discussion on class of service and how that could be arranged in a label stack. The CoS could use the EXP bits on the transport label. However, it needs to be checked whether/how different CoS could be “propagated” through the label stack e.g., in a case where “detnet PW” labels/flows have different CoS needs. Need to check whether this is sufficient as a way forward.

Need some more thinking:
 * CoS (see above)
 * Any need for timestamps (we did not discuss this, but see IETF97 presentation about RTP headers)?

Next call:
 Tue 1/31/2017 the usual time.


--
Jouni Korhonen, Broadcom Ltd.
M: [phone]