| DetNet | J. Korhonen, Ed. |
| Internet-Draft | Broadcom |
| Intended status: Informational | L. Andersson |
| Expires: September 14, 2017 | Y. Jiang |
| Huawei | |
| B. Varga | |
| J. Farkas | |
| Ericsson | |
| CJ. Bernardos | |
| UC3M | |
| T. Mizrahi | |
| Marvell | |
| March 13, 2017 |
DetNet Data Plane solution
draft-dt-detnet-dp-sol-00
This document specifies a PseudoWire-based Deterministic Networking data plane solution. The data plane solution can be applied over either IP or MPLS Packet Switched Networks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies a Deterministic Networking (DetNet) data plane solution. The solution is based on PseudoWires (PW) [RFC3985] and makes use of the multi-segment (MS-PW) [RFC6073] to map DetNet Relay and Edge Nodes [I-D.ietf-detnet-architecture][I-D.ietf-detnet-dp-alt] to PW architecture. The PW-based data plane can be run over either an IP or MPLS [RFC4448][RFC6658] Packet Switched Network (PSN).
For the purpose of DetNet data plane, this document specifically specifies the PW encapsulation for DetNet flows, a DetNet Control Word (CW), a DetNet label, how MS-PW derived DetNet Relay and Edge nodes work, and as a specific new PW feature how the Packet Replication and Elimination function (PREF) is implemented using PWs. This document does not define the associated control plane functions, or operations and management (OAM).
This document uses the terminology established in the DetNet architecture [I-D.ietf-detnet-architecture] and the DetNet Data Plane Solution Alternatives [I-D.ietf-detnet-dp-alt].
The following terms are also used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL" "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
[Ed. to be written.. describe the scope here fot this document: this document only addresses the inter-connect case i.e., 802.1 over routed network (enlarge the layer-2 domain - EVPAN', and the native DetNet case.]
TSN Edge Transit Relay DetNet
End System Node Node Node End System
+---------+ +.........+ +---------+
| Appl. |<---:Svc Proxy:-- End to End Service ---------->| Appl. |
+---------+ +---------+ +---------+ +---------+
| TSN | |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |
+---------+ +---+ +---+ +---------+ +---------+ +---------+
|Transport| |Trp| |Trp| |Transport| |Trp| |Trp| |Transport|
+-------.-+ +-.-+ +-.-+ +--.----.-+ +-.-+ +-.-+ +---.-----+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub ]-+ +........+ +-[ Sub ]-+
[Network] [Network]
`-----' `-----'
Figure 1: A simple DetNet enabled network architecture
Figure 2 illustrates how DetNet can provide services for IEEE 802.1TSN end systems over a DetNet enabled network. The edge nodes insert and remove required DetNet data plane encapsulation. The 'X' in the edge and relay nodes represents a potential DetNet flow packet replication and elimination point. This conceptually parallels L2VPN services, and could leverage existing related solutions as discussed below.
TSN |<---------- End to End DetNet Service ------>| TSN
Service | Transit Transit | Service
TSN (AC) | |<-Tunnel->| |<-Tnl->| | (AC) TSN
End | V V 1 V V 2 V V | End
System | +--------+ +--------+ +--------+ | System
+---+ | |DA-T-PE1|==========|DA-S-PE1|=======|DA-T-PE2| | +---+
| |--|----|._X_....|..DetNet..|.._ _...|..DF3..|...._X_.|---|---| |
|CE1| | | \ | Flow 1 | X | | / | | |CE2|
| | | \_.|...DF2....|._/ \_..|..DF4..|._/ | | |
+---+ | |==========| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Edge Node Relay Node Edge Node |
| |
|<----- Emulated Time Sensitive Networking (TSN) Service ---->|
Figure 2: IEEE 802.1TSN over DetNet
Figure 3 illustrates how end to end DetNet service can be provided. In this case, the end systems are able to send and receive DetNet flows. For example, put application data in PseudoWire (PW) and encapsulated in IP. Like earlier the 'X' in the end systems, edge and relay nodes represents potential DetNet flow packet replication and elimination points. Here the relay nodes may change the underlying transport, for example replacing IP with MPLS or tunneling IP over MPLS, or simply interconnect network segments.
DetNet DetNet
Service Transit Transit Service
DetNet | |<-Tnl->| |<-Tnl->| | DetNet
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | |DA-S-PE1|=======|DA-S-PE2|=======|DA-S-PE3| | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node |
| |
|<-- End to End Time Sensitive Networking (TSN) Service -->|
Figure 3: Native DetNet
Two major groups of scenarios can be distinguished which require flow identification during transport:
Each node (DA-T-PE, DA-S-PE and P) use a local-ID of the DetNet-(compound)-flow in order to accomplish its role during transport. Recognizing the flow-ID is more relaxed for DA-T-PE and DA-S-PE nodes, as they are fully aware of both the DetNet service and transport layers. The DetNet role of intermediate "P" nodes is limited to ensure congestion protection from the above listed DetNet functions. However, P nodes can usually recognize only "T-label" and cannot consider the whole label stack for flow recognition. Therefore, identifying each individual DetNet flow on a P node may not be achieved in some network scenarios.
On each node dealing with DetNet flows, a local-ID is assumed to determine what local operation a packet goes through. Therefore, local-IDs MUST be unique on each DA-T-PE and DA-S-PE nodes. Local-ID MUST be unambiguously bound to the Flow-ID encoded in the DetNet packet.
The DetNet control word (d-CW) is identical to the control word defined for Ethernet over MPLS networks in [RFC4448]. The DetNet control word is illustrated in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| reserved - set to 0 | 16 bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DetNet Control Word
[Editor's note: Shoudl we care about high speed links, here 16 bits of sequence number wraps fast? For example, in a case of 100Gb/s link, 16 bits of sequence number will wrap in ~6.6ms assuming 1250 octets of packets and ~3.3ms for 625 octets packets. Both numbers mean quite long fiber distances, though.]
The DetNet flow identity word (flow-ID) identifies a DetNet flow uniquely within a DetNet network. The flow-ID is also associated with the sequence number carried in the DetNet control word and used also for PREF purposes.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |D| 24 bit flow identity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DetNet flow identity word
The management and assignment of the flow-IDs is outside of this specification. It is assumed that each DA-T-PE node have either a preconfigured flow-ID number space or some dynamic control plane protocol is able to coordinate the allocation of the flow-IDs across the DA-T-PE nodes, or a central entity, e.g., a Software Defined Networking controller.
The D bit defines the direction of the flow. The value 0 means 'east' and the value 1 means 'west'. The D bit can be used in ring topologies to allow DetNet flows with the same flow-ID cross with or without PREF processing taking place. Whether a DA-*-PE checks for the D bit is based on a local policy setting. The support for D bit is optional. If a DA-*-PE does not support the D bit it MUST be treated as 0.
The reserved field in the flow-ID MUST be set to zero and ignored when received.
[Editor's note: we need some configuration knob defined for this feature.]
The DetNet data plane follows PW encapsulation. This document specifies a single encapsulation that can be used over both MPLS and IP packet switched Networks (PSN). The DetNet data plane encapsulation consists of a
In a case of MPLS-based PSN, the tunnel labels between LSRs are referred as T-labels.
The DetNet CW and the Detnet flow-ID together constitute the DetNet PseudoWire encapsulation header.
Figure 6 illustrates a DetNet PseudoWire encapsulation using an MPLS PSN. Similarly, Figure 7 illustrates the DetNet PseudoWire encapsulation when IP PSN is used. The encapsulation is uniform above the PSN.
Depending on the network topology the "overlay label" (L-label) may be part of the label stack. The L-label tunnels guarantee PW labels remain unchanged between DA-*-PE nodes. Furthermore, L-labels tunnels allow selectively exposing the PW label to DA-*-PE nodes, which means some overlay topologies may just pass through specific DA-S-PEs without any DetNet specific processing.
RFC3985 Encapsulation DetNet PW Encapsulation
+---------------------------------+
+---------------------+ | |
| Payload | | DetNet Flow |
/=====================\ | Payload Packet |
H Payload Convergence H--. | |
H---------------------H | /=================================\
H Timing H +-\ H DetNet Flow ID H
H---------------------H | \--->H---------------------------------H
H Sequencing H--' H DetNet Control Word H
\=====================/ \=================================/
| PW Demultiplexer |--------->| PW Label |
+---------------------+ +---------------------------------+
| PSN Convergence | .--->| Optional Topology overlay Label |
+---------------------+ | +---------------------------------+
| PSN |-----+--->| MPLS T-Label(s) |
+---------------------+ +---------------------------------+
| Data-Link |
+---------------------+
| Physical |
+---------------------+
Figure 6: Encapsulation of a DetNet flow in a PW with MPLS(-TP) PSN
When IP PSN is used, the label stack it transports is only inspected when the IP packet destination address equals to the IP address of a DA-*-PE or a P node. Essentially there are one more IP tunnels between a number of DA-*-PE and/or P nodes. The LFIB and the forwarding information base (FIB) combination determines whether a PW gets terminated at the node or forwarded to another node within a new IP tunnel.
RRC3985 Encapsulation DetNet PW Encapsulation
+---------------------------------+
+---------------------+ | |
| Payload | | DetNet Flow |
/=====================\ | Payload Packet |
H Payload Convergence H--. | |
H---------------------H | /=================================\
H Timing H +-\ H DetNet Flow ID H
H---------------------H | \--->H---------------------------------H
H Sequencing H--' H DetNet Control Word H
\=====================/ \=================================/
| PW Demultiplexer |--------->| PW Label |
+---------------------+ +---------------------------------+
| PSN Convergence | .--->| Optional Topology overlay Label |
+---------------------+ | +---------------------------------+
| PSN |-----+ | Optional UDP Header |
+---------------------+ | +---------------------------------+
| Data-Link | `--->| IPv4 or IPv6 header |
+---------------------+ +---------------------------------+
| Physical |
+---------------------+
Figure 7: Encapsulation of a DetNet flow in a PW with IP PSN
[Editor's note: The Detnet-aware "extended forwarder" does the heavy lifting on maintaining the sequence numbers associated with the DetNet labels. Extended forwarder is also responsible for packet replication and duplicate elimination. See the excerpt from RFC3985 Section 4.2.1. about forwarder's functions. We extend that to PREF:
]
The DetNet specific new functionality in a DA-*-PE PW processing is the packet replication and duplication elimination function (PREF). This functional is a part of the "extended" forwarder. The PREF processing is triggered by the LFIB actions i.e., not all PWs receive DetNet specific processing. Basically the LFIB has to be extended with a "PREF enabled" boolean configuration switch that is associated with the normal label actions (e.g., swap, push, pop, ..). The output of the PREF elimination function is always a single packet. The output of the PREF replication function is always one or more packet (i.e., 1:M replication). The replicated packets MUST share the same DetNet PW control word sequence number and flow identity word flow-id.
The complex part of the DetNet PREF processing is tracking the history of received packets for multiple PWs. These PWs do not have the same PW label value while they still share the same PW sequence number counter and the history information. That is where the DetNet encapsulation header flow-ID plays an important role and binds the control word sequence number to the flow specific shared counter and history information within the PREF function.
The DetNet flow word contains a D flag bit (see Section 5.2), which makes the DA-*-PE node aware of the direction the flow-ID arrived from. If the node, based on the local policy, checks for the D bit setting that effectively means the sequence number history has to contain also the D bit information.
[Editor's note: draw here an example of LFIB with the elimination action.]
The PW-based DetNet data plane solution overloads the T-PE with a DetNet Edge Node function. Such T-PE is referred as DA-T-PE and implies the T-PE is also aware of DetNet flows and may need to operate upon those. Figure 8 illustrates the overall DA-T-PE device functions. The figure shows both physical attachment circuit (AC) (e.g., Ethernet [RFC4448]) connecting to the PE, and a packet service connecting to the PE via an embedded label switching router (LSR) function [RFC6658]. Whether traffic flow from from a client AC and PSN LSP receives DetNet specific treatment is up to a local configuration and policy. A DA-T-PE can also serve as a normal T-PE.
+---------------------------------------+
| DA-T-PE Device |
+---------------------------------------+ Egress/
| | Forwarder | | Ingress
| LSR | | Single | PW Instance
Client PSN | ("Packet o <-X-----> o PW Instance o<---------->
LSPs | NSP") | | Repl. | |
<---------->o | | Elim. +-------------+ Duplicate
| | : | | Egress
| | . | Single | PW Instance
| | +-> o PW Instance o<---------->
| | | | |
+-------------+ | +-------------+ Egress/
| | | | | Ingress
Client AC | NSP | Repl. | | Single | PW Instance
<---------->o o <-----X-> o PW Instance o<---------->
| | Elim. | |
+-------------+ +-------------+ Egress/
| | | | Ingress
Client AC | NSP | | Single | PW Instance
<---------->o o <-------> o PW Instance o<---------->
| | | |
+---------------------------------------+
Figure 8: DetNet Edge Node as a DA-T-PE
A DA-T-PE participates to the packet replication and duplication elimination. Required processing is done within an extended forwarder function. In the case the native service processing (NSP) is IEEE 802.1CB [IEEE8021CB] capable, the packet replication and duplicate elimination MAY entirely be done in the NSP and bypassing the DetNet PW encapsulation and logic entirely, and thus is able to operate over unmodified PW implementation and deployment. The NSP approach works only between DA-T-PEs and cannot make use of DA-S-PEs (see Section 6.3).
The DetNet-aware extended forwarder selects the egress segment PW based on the rules described in [RFC4448] and [RFC6658]. In both "normal AC" and "Packet AC" cases there is no DetNet encapsulation header available yet as it is the case with DA-S-PEs (see Section 6.3). It is the responsibility of the extended forwarder within the DA-T-PE to push the DetNet encapsulation header (i.e., the DetNet CW and the DetNet flow-ID) to the packet before forwarding it to the appropriate egress PW instance(s). The extended forwarder MAY copy the sequencing information from the native packet into the DetNet CW and vice versa. If there is no existing sequencing information available in the native packet or the forwarder chose not to copy it from the native packet, then the extended forwarder MUST maintain a sequence number counter for each DetNet flow (indexed by the flow-ID).
The PW-based DetNet data plane solution overloads a S-PE with a DetNet Relay function. Such S-PE device is referred as DA-S-PE and implies the S-PE is also aware of DetNet flows and may operate upon those. Figure 9 illustrates the overall DA-S-PE device functions.
A DA-S-PE participates to the packet replication and duplication elimination. This processing is done within an extended forwarder function. Whether an ingress PW receives DetNet specific processing depends on how the LFIB is programmed. For some PWs the DA-S-PE can act as a normal S-PE and for some apply the DetNet specific processing. It is also possible to treat the DA-S-PE as a P router using the L-label tunnels. Again, this is entirely up to how the LFIB has been programmed.
The DetNet-aware forwarder selects the egress segment PW based on the PW label. The mapping of ingress PW label to egress PW label may be statically or dynamically configured. Additionally the DetNet-aware forwarder does duplicate frame elimination based on the DetNet flow-ID and DetNet Control Word sequence number combination. The packet replication is also done within the DetNet-aware forwarder. During elimination and the replication process both DetNet CW sequence number and DetNet flow-ID MUST be preserved and copied to the egress PW.
+---------------------------------------+
| DA-S-PE Device |
+---------------------------------------+
Ingress | | Forwarder | | Egress
PW instance | Single | | Single | PW Instance
----------->o PW Instance o --X-----> o PW Instance o----------->
| | | Elim. | |
+-------------+ | +-------------+ Duplicate
Ingress | | | | | Egress
PW instance | Single | | | Single | PW Instance
----------->o PW Instance o --+ +-> o PW Instance o----------->
| | | | |
+-------------+ | +-------------+
Ingress | | | | | Egress
PW instance | Single | Repl. | | Single | PW Instance
----------->o PW Instance o ------X-> o PW Instance o----------->
| | | |
+-------------+ +-------------+
Ingress | | | | Egress
PW instance | Single | | Single | PW Instance
----------->o PW Instance o --------> o PW Instance o----------->
| | | |
+---------------------------------------+
Figure 9: DetNet Relay Node as a DA-S-PE
[Editor's note: Discuss the CoS.. and how that is archived when using MPLS or IP PSN.]
[Editor's note: Elaborate the QoS issues here..]
[Editor's note: describe a bit of issues and deployment considerations related to time-synchronization within DetNet. Refer to DT discussion and the slides that summarize different approaches and rough synchronization performance numbers. Finally, scope time-synchronization solution outside data plane.]
When DetNet is used, there is an underlying assumption that a clock synchronization method is used, such as the Precision Time Protocol (PTP) [IEEE1588]. In this case, there are a few possible approaches of how synchronization protocol packets are forwarded and handled by the network:
It is expected that the latter approach will be the most common one, as it provides the highest degree of accuracy, and creates a layer separation between the DetNet data and the synchronization service.
It should be noted that in all three approaches it is not recommended to use replication and elimination for synchronization packets; the replication/elimination approach may in some cases reduce the synchronization accuracy, since the observed path delay will be bivalent.
Some DetNet applications generate bidirectional traffic and may require symmetric flows. There are already mechanisms that can be used to create bidirectional tunnels at the transport network level, such as MPLS-TP. The data plane solution SHOULD allow establishing bidirectional symmetric flows. Control plane mechanisms would need to also support this, though this is out of scope of this document. [Summary of existing mechanisms to create bidirectional tunnels that can be used.]
[Editor's note: discuss here what kind of enhancements are needed for DetNet and specifically for PREF.]
The PW label distribution follows the same mechanisms specified for MS-PW [RFC6073].
The security considerations of DetNet in general are discussed in [I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other security considerations will be added in a future version of this draft.
TBD.
The author(s) ACK and NACK.
The following people were part of the DetNet Data Plane Solution Design Team:
The DetNet chairs serving during the DetNet Data Plane Solution Design Team:
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3985] | Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005. |
| [RFC4448] | Martini, L., Rosen, E., El-Aawar, N. and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006. |
| [RFC6073] | Martini, L., Metz, C., Nadeau, T., Bocci, M. and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011. |
| [RFC6658] | Bryant, S., Martini, L., Swallow, G. and A. Malis, "Packet Pseudowire Encapsulation over an MPLS PSN", RFC 6658, DOI 10.17487/RFC6658, July 2012. |
| [I-D.ietf-detnet-architecture] | Finn, N. and P. Thubert, "Deterministic Networking Architecture", Internet-Draft draft-ietf-detnet-architecture-00, September 2016. |
| [I-D.ietf-detnet-dp-alt] | Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., Zhuangyan, Z. and L. Berger, "DetNet Data Plane Protocol and Solution Alternatives", Internet-Draft draft-ietf-detnet-dp-alt-00, October 2016. |
| [I-D.sdt-detnet-security] | Mizrahi, T., Grossman, E., Hacker, A., Das, S., "Deterministic Networking (DetNet) Security Considerations, draft-sdt-detnet-security, work in progress", 2017. |
| [IEEE1588] | IEEE, "IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", 2008. |
| [IEEE8021CB] | Finn, N., "Draft Standard for Local and metropolitan area networks - Seamless Redundancy", IEEE P802.1CB /D2.1 P802.1CB, December 2015. |
[Editor's note: Simplified example of DetNet data plane and how labels etc work in the case of MPLS-based PSN and utilizing PREF. The figure is subject to change depending on the further DT decisions on the label handling..]
T1 ->R1----->DA-S-PE1---->R2---->DA-S-PE2--->R3
L1 / L1 T2 L2 T3 \ L2
PW1 / PW1 L2 PW1 L2 \ PW1
#seq / #seq PW1 #seq PW1 \ #seq
FID1 / FID1 #seq FID1 #seq \ FID1
/ FID1 v
E1-->DA-T-PE1 DA-T-PE2-->E3
\ T5 T6 ^
T4 \ L2 L3 L4 L5 /
L2 \ PW1 PW2 PW1 PW2 /
PW1 \ #seq #seq #seq #seq /
#seq \ FID1 FID2 FID1 FID2 /
FID1 =>R4------------->DA-S-PE2--------------->R5
T11 / ^ \ L5
L3 / \ L9 \ PW2
PW2 / \ PW2 \ #seq
#seq / \ #seq \ FID2
FID2 / \ FID2 v
E2-->DA-T-PE3 R9<- T10 DA-T-PE4-->E4
\ T8 \ L9 T9 ^
T7 \ L6 L7 L7 \ PW2 L8 / L8
L6 \ PW2 PW2 PW2 \ #seq PW2 / PW2
PW2 \ #seq #seq #seq \FID2 #seq / #seq
#seq \ FID2 FID2 FID2 \ FID2 / FID2
FID2 ->R6---->DA-S-PE2---->R7---->DA-S-PE6---->R8
Figure 10: Replication and elimination example
[Editor's note: the LFIB Figure 11 content to be updated.]
+========+================+=====================================+ | | | PREF | Forwarding Semantics | | Device | In-Label |--------------|----------------------| | | | flow-ID | D | Out-Label | Out-Link | +========+================+==========+===+===========+==========+ | T-PE1 | N/A (from AC) | | | | | | | | | | | | +========+================+==========+===+===========+==========+ | T-PE2 | | | | | | | | | | | | | +========+================+==========+===+===========+==========+ | T-PE3 | N/A (from AC) | | | | | | | | | | | | +========+================+==========+===+===========+==========+ | T-PE4 | | | | | | | | | | | | | +========+================+==========+===+===========+==========+ | S-PE1 | | | | | | +========+================+==========+===+===========+==========+ | S-PE2 | | | | | | +========+================+==========+===+===========+==========+ | S-PE3 | | | | | | +========+================+==========+===+===========+==========+ | S-PE4 | | | | | | +========+================+==========+===+===========+==========+ | S-PE5 | | | | | | +========+================+==========+===+===========+==========+ | S-PE6 | | | | | | +========+================+==========+===+===========+==========+ | R1 | | N/A | | | | +========+================+==========+===+===========+==========+ | R2 | | N/A | | | | +========+================+==========+===+===========+==========+
Figure 11: LFIB contents