Beruflich Dokumente
Kultur Dokumente
Version: v1.0
Abstract: This Application Notes describes the configuration of a specific feature of the Thomson
Gateway: VLAN Bridging. This feature is explained by integrating the Thomson Gateway in a
scenario where untagged, priority-tagged or VLAN-tagged frames have to be bridged between
the local Ethernet segment and the DSL line. The practical realization of the scenario is
described using CLI commands.
Applicability: This Application Note applies to all Thomson DSL Gateways with R7.4 and higher.
Updates: Thomson continuously develops new solutions, but is also committed to improving its existing
products.
For more information on Thomson's latest technological innovations, documents and software
releases, visit us at http://www.thomson-broadband.com
Contents
1 Introduction.................................................................................. 3
6 VLAN ID Translation.................................................................. 21
6.1 Scenario Overview ........................................................................................ 21
2 E-DOC-CTC-20080229-0004 v1.0
Chapter 1
1 Introduction
VLANs
The Ethernet frames that have to be forwarded may reside in different VLANs. This implies that all Ethernet
frames contain a (802.1Q) VLAN ID. Communication between different VLANs is not allowed on the link layer.
Only routers can make connections between different VLANs. VLANs create thus separated logical Ethernet
segments within a single physical segment.
Ethernet QoS
Ethernet frames optionally contain a (802.1p) user priority indication. If Ethernet QoS is taken into account
during bridging, it can be based on two steps:
1 Mapping the user priority of an incoming frame to an internal priority class. This classification can be
based on:
The type of the interface on which the frame is entering the bridge.
The (802.1p) user priority value.
The IP Type of Service octet (TOS-byte) for IP packets, using the Precedence or DSCP notation.
2 Sending out the frame while taking into account its internal priority class. This class can be used to:
Perform priority queuing on a single PVC.
Perform traffic multiplexing over a range of PVCs.
Related documents
For detailed information on the features, CLI commands and parameters used in this document, see:
Thomson Gateway Ethernet Configuration Guide.
Thomson Gateway VLAN Configuration Guide.
Thomson Gateway Ethernet QoS Configuration Guide.
E-DOC-CTC-20080229-0004 v1.0
3
Chapter 2
2 Port-to-PVC Mapping
Introduction
In this scenario, the Thomson Gateway is intended to classify untagged Ethernet frames based on the
receiving local interface. Per local interface, you have to be able to configure to which PVC the frames must
be forwarded.
This scenario configures the Thomson Gateway as bridge with two PVCs. Traffic on all local interfaces, except
for one, is forwarded to the first PVC. Traffic on a specific local interface is forwarded to the second PVC. For
example, you can use one PVC for normal Internet traffic and a second PVC for multicast traffic.
Following illustration shows the port-to-PVC mapping scenario:
Thomson Gateway DSLAM
PVC1
PVC2
Mechanisms
To set up this scenario, we use following mechanisms:
VLANs: the Ethernet bridge uses VLANs to forward traffic to different PVCs. Configuring the VLAN
membership of the bridge ports enables you to configure from which local interface to which PVC the
traffic must be forwarded.
Port isolation: this term is used when a bridge port is added to a VLAN and explicitly removed from the
default VLAN.
Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario:
1 Define which PVCs must be used by configuring an ATM interface for each one of them.
2 Connect the ATM interfaces to the Ethernet bridge.
3 Make the bridge VLAN aware.
4 E-DOC-CTC-20080229-0004 v1.0
Chapter 2
=>:saveall
To create, configure and connect ATM interfaces on top of these phonebook entries, execute following CLI
commands:
E-DOC-CTC-20080229-0004 v1.0
5
Chapter 2
Create a VLAN
To define the VLAN to be used, execute following CLI command:
A logical name is associated with the effective VID that is used by the Ethernet bridge for that VLAN. The
addrule=disabled parameter forces the Thomson Gateway to create a separate filtering database for the
created VLAN. As a result, the same MAC address (e.g. the DSLAM MAC address) can be used in different
VLANs, for example when different VLANs are connected to the same device (e.g. the DSLAM).
Configure port isolation of the bridge_PVC2 bridge port: add the bridge port (WAN interface) to the new
VLAN and explicitly remove it from the default VLAN, executing following CLI commands:
=>:saveall
Expected result
To display the list of VLANs on the Ethernet bridge, execute following CLI command:
6 E-DOC-CTC-20080229-0004 v1.0
Chapter 2
To retrieve an overview of the population of the different VLANs, execute following CLI command:
Each bridge port is member of a single VLAN. Untagged frames received on a bridge port are only forwarded
to bridge ports that are member of the same VLAN:
Frames received on bridge port 4 are forwarded to PVC2 and vice versa.
Frames received on other bridge ports are forwarded within the default VLAN.
E-DOC-CTC-20080229-0004 v1.0
7
Chapter 3
3 VLAN-Transparent Forwarding
Introduction
In this scenario, the Thomson Gateway is intended to forward all VLAN-tagged frames between the local
Ethernet segment and a PVC transparently.
This scenario configures the Thomson Gateway as bridge with one PVC. All incoming frames on all local
interfaces have to be forwarded transparently to this PVC. The PVC to which all traffic has to be forwarded, is
chosen at configuration time. The exact value of the VLAN ID (VID) or the user priority indication should not
influence the result.
Following illustration shows the VLAN-transparent forwarding scenario:
Thomson Gateway DSLAM
A 5
A 2
A 5 B 7 C 1
B 7
A 2 B 3
B 3
C 2
PVC1
C 2
C 1
Mechanism
To set up this scenario, we use following key mechanism: we explicitly define that the Ethernet bridge is not
VLAN aware. Ethernet frames coming in on the Thomson Gateway have a VLAN tag in their header. However,
neither the VLAN ID nor the user priority indication should be taken into account. If the Ethernet bridge is
VLAN aware, we have to define all VLANs that have to pass through the Thomson Gateway. Otherwise,
unknown VLANs are dropped.
Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario:
1 Define which PVC must be used by configuring an ATM interface for it.
2 Connect the ATM interface to the Ethernet bridge.
3 Define that the bridge is not VLAN aware.
4 Save the configuration.
8 E-DOC-CTC-20080229-0004 v1.0
Chapter 3
=>:saveall
To create, configure and connect an ATM interface on top of this phonebook entry, execute following CLI
commands:
E-DOC-CTC-20080229-0004 v1.0
9
Chapter 3
If necessary, disable the VLAN awareness of the Ethernet bridge executing following CLI command:
=>:saveall
Expected result
All incoming frames on a local interface are forwarded to the configured PVC. The same is true for frames
arriving on the Thomson Gateway via the DSL line: these frames are forwarded to the local Ethernet
segment.
Whether the frame has a VLAN tag or not is irrelevant for the current scenario. All frames are forwarded in
both directions.
In this statement, all frames has to be understood as all frames that should be forwarded by a
regular bridge. There are exceptions, for example, administered reserve multicast destination
addresses.
10 E-DOC-CTC-20080229-0004 v1.0
Chapter 4
Introduction
In this scenario, the Thomson Gateway is intended to classify VLAN-tagged Ethernet frames based on their
VLAN ID. Per VLAN ID, you have to be able to configure to which PVC the frames must be forwarded.
This scenario configures the Thomson Gateway as bridge with two PVCs. Frames coming in on a local
interface are checked on their VLAN ID and are only forwarded on PVCs that are member of the same VLAN.
For example, frames that are member of VLAN A are forwarded to the first PVC. Frames that are member of
VLAN B or VLAN C are forwarded to the second PVC. The receiving local interface should not influence the
result.
Following illustration shows the VLAN ID-based forwarding scenario:
Thomson Gateway DSLAM
A 5
A 5
A 2 A 2
B 7 PVC1
B 3 B 7 C 1
B 3
C 2
C 2
PVC2
C 1
Mechanisms
To set up this scenario, we use following mechanisms:
VLAN awareness: the Ethernet bridge must be fully VLAN aware. As a result, the Ethernet bridge takes
the VLAN tag in the header of received frames into account.
VLANs: several VLANs are created on the Thomson Gateway. The local interfaces must be member of all
possible VLANs that can appear in the VLAN tag of received frames. The configured VLAN membership
of the PVCs defines to which PVC the frames must be forwarded.
Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario:
1 Define which PVCs must be used by configuring an ATM interface for each one of them.
2 Connect the ATM interfaces to the Ethernet bridge.
3 Make the bridge VLAN aware.
E-DOC-CTC-20080229-0004 v1.0
11
Chapter 4
4 Define a VLAN for each VLAN ID the Ethernet bridge has to handle.
5 Define which interfaces are part of which VLAN.
6 Save the configuration.
=>:saveall
To create, configure and connect the ATM interfaces on top of the phonebook entries, execute following CLI
commands:
12 E-DOC-CTC-20080229-0004 v1.0
Chapter 4
From this moment on, all Ethernet frames coming in on the Ethernet bridge with a VLAN tag are only
forwarded to interfaces configured as an explicit member of that VLAN.
A logical name is associated with the effective VID that is used in the VLAN tag of the frame. The
addrule=disabled parameter forces the Thomson Gateway to create a separate filtering database for the
created VLAN. As a result, the same MAC address (e.g. the DSLAM MAC address) can be used in different
VLANs, for example when different VLANs are connected to the same device (e.g. the DSLAM).
The untagged=disabled parameter avoids that the VLAN tag is stripped off when the frames are sent out on
the interface.
The untagged=disabled parameter avoids that the VLAN tag is stripped off when the frames are sent out on
the interface.
E-DOC-CTC-20080229-0004 v1.0
13
Chapter 4
=>:saveall
Expected result
To display the list of VLANs on the Ethernet bridge, execute following CLI command:
To retrieve an overview of the population of the different VLANs, execute following CLI command:
Frames received on a bridge port are checked for their VLAN ID and are only sent out on bridge ports that are
member of the same VLAN. The table above shows that frames with VID 10 (representing VLAN A) are only
transmitted on PVC1. Frames with VID 11 (VLAN B) or 12 (VLAN C) are transmitted on PVC2.
It can be seen that all interfaces are also member of the default VLAN, and, as a result, also have connectivity
with the Thomson Gateway.
For example, to accept only VLAN-tagged frames on bridge port 4, execute following command:
14 E-DOC-CTC-20080229-0004 v1.0
Chapter 4
Additionally, you can use following CLI command to prevent the Thomson Gateway from modifying the user
priority indication in the VLAN tag:
E-DOC-CTC-20080229-0004 v1.0
15
Chapter 5
Introduction
In this scenario, the Thomson Gateway is intended to forward VLAN-tagged frames between the local
Ethernet segment and PVCs. For a limited number of VLAN IDs, you have to be able to configure to which
PVC the frames must be forwarded. For all other VLAN IDs, the frames have to be forwarded transparently to
a single PVC. This PVC is also selected at configuration time.
This scenario configures the Thomson Gateway as bridge with two PVCs. One local interface receives frames
that are member of VLAN A. These frames are forwarded to the first PVC. Another local interface receives
frames that are member of several other VLANs. All these frames are forwarded to the second PVC.
Following illustration shows the unknown VLAN forwarding scenario:
Thomson Gateway DSLAM
A 5 A 5
A 2 A 2
PVC1
B 7 B 7 C 1
X 2
Y 3
C 1 Y 3 X 2
PVC2
Mechanism
To set up this scenario, we use following mechanisms:
VLAN awareness: the Ethernet bridge must be VLAN aware. As a result, the Ethernet bridge takes the
VLAN tag in the header of received frames into account.
VLANs: VLAN A is created on the Thomson Gateway. The configured VLAN membership of the interfaces
defines from which local interface to which PVC the frames must be forwarded.
Unknown VID policy: this mechanism avoids the need to configure all possible VLANs that can appear in
the VLAN tag of received frames. A special VLAN, the unknown VLAN, is created on the Ethernet bridge.
This way, all frames that are member of VLANs that are not explicitly configured, can be forwarded
transparently.
Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario:
1 Define which PVCs must be used by configuring an ATM interface for each one of them.
16 E-DOC-CTC-20080229-0004 v1.0
Chapter 5
=>:saveall
To create, configure and connect the ATM interfaces on top of these phonebook entries, execute following CLI
commands:
E-DOC-CTC-20080229-0004 v1.0
17
Chapter 5
From this moment on, all Ethernet frames arriving on the Ethernet bridge with a VLAN tag are only forwarded
to interfaces configured as an explicit member of that VLAN.
A logical name is associated with the effective VID that is used in the VLAN tag of the frame. The
addrule=disabled parameter forces the Thomson Gateway to create a separate filtering database for the
created VLAN. As a result, the same MAC address (e.g. the DSLAM MAC address) can be used in different
VLANs, for example when different VLANs are connected to the same device (e.g. the DSLAM).
The VLAN membership of the WAN-side bridge ports defines to which PVCs the frames are forwarded. In this
example, frames of VLAN A are forwarded to the first PVC.
To put the ATM-based bridge port for the first PVC in VLAN A, execute following CLI command:
The untagged=disabled parameter avoids that the VLAN tag is stripped off when the frames are sent out on
the interface.
18 E-DOC-CTC-20080229-0004 v1.0
Chapter 5
To put Ethernet port 3 and the second PVC in the unknown VLAN, execute following CLI command:
The untagged=disabled parameter avoids that the VLAN-header is stripped off when the frames are sent out
on the interface.
=>:saveall
Expected result
To display the list of known VLANs on the Ethernet bridge, execute following CLI command:
To retrieve an overview of the population of the different VLANs, execute following CLI command:
To retrieve an overview of the population of the unknown VLAN, execute following CLI command:
Frames received on a bridge port are checked for their VLAN ID and are only sent out on bridge ports that are
member of the same VLAN. The table above shows that frames with VID 10 (representing VLAN A) are only
transmitted on PVC1. Frames with any other VID are transmitted transparently on PVC2.
It can be seen that all interfaces are also member of the default VLAN, and, as a result, also have connectivity
with the Thomson Gateway.
E-DOC-CTC-20080229-0004 v1.0
19
Chapter 5
Untagged frames:
For example, to assign untagged frames to the default VLAN, execute following CLI command:
For example, to accept only VLAN-tagged frames on bridge port 2, execute following command:
Additionally, you can use following CLI command to prevent the Thomson Gateway from modifying the user
priority indication in the VLAN tag:
20 E-DOC-CTC-20080229-0004 v1.0
Chapter 6
6 VLAN ID Translation
Introduction
In this scenario, the Thomson Gateway is intended to forward VLAN-tagged Ethernet frames between the
local Ethernet segment and the PVCs. The local VID of a frame received on a local interface is translated to a
WAN-side VID before the frame is sent out on a WAN interface. Per interface and per VLAN ID, you have to be
able to configure the translation from a local VID to a WAN-side VID.
This scenario configures the Thomson Gateway as bridge with one PVC. Frames coming in on a local
interface are checked on VLAN ID and are only forwarded on PVCs that are member of the same VLAN.
Before the frame is sent out by the PVC, the VLAN ID is translated. For example, a local VID A is translated
into a WAN-side VID Z.
Following illustration shows the VLAN ID translation scenario:
Thomson Gateway DSLAM
A 5 Z 5
A 2 Z 2
PVC1
Mechanisms
To set up this scenario, we use following mechanisms:
VLAN awareness: the Ethernet bridge must be fully VLAN aware. As a result, the Ethernet bridge takes
the VLAN tag in the header of received frames into account.
VLANs: several VLANs are created on the Thomson Gateway. The configured VLAN membership of the
interfaces defines to which PVC the frames must be forwarded.
Extra tagging (stacked VLANs): this mechanism enables the use of a VID translation table. The VID
translation table defines, per interface and per local VID, the mapping between the local VID and the
WAN-side VID.
Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario:
1 Define which PVC must be used by configuring an ATM interface.
E-DOC-CTC-20080229-0004 v1.0
21
Chapter 6
=>:saveall
To create, configure and connect an ATM interface on top of this phonebook entry, execute following CLI
commands:
22 E-DOC-CTC-20080229-0004 v1.0
Chapter 6
From this moment on, all Ethernet frames arriving on the Ethernet bridge with a VLAN tag are only forwarded
to interfaces configured as an explicit member of that VLAN.
A logical name is associated with the effective VID that is used in the VLAN tag of the frame. The
addrule=disabled parameter forces the Thomson Gateway to create a separate filtering database for the
created VLAN. As a result, the same MAC address (e.g. the DSLAM MAC address) can be used in different
VLANs, for example when different VLANs are connected to the same device (e.g. the DSLAM).
The VLAN membership of the WAN-side bridge ports defines to which PVCs the frames are forwarded. In this
example, frames of VLAN A must be forwarded to PVC1. The untagged=enabled parameter means that the
VLAN tag is stripped off when the frames are sent out on the interface.
To put PVC1 in VLAN A, execute following CLI command:
To remove PVC1 from the default VLAN, execute following CLI command:
To map the local VID 10 (VLAN A) to the WAN-side VID 4010 (VLAN Z), execute following command:
E-DOC-CTC-20080229-0004 v1.0
23
Chapter 6
=>:saveall
Expected result
To display the list of VLANs on the Ethernet bridge, execute following CLI command:
To retrieve an overview of the population of the different VLANs, execute following CLI command:
Frames received on a bridge port are checked for their VLAN ID and are only sent out on bridge ports that are
member of the same VLAN. The table above shows that frames with VID 10 (representing VLAN A) are only
transmitted on PVC1. Using the extra tagging feature on PVC1, two tags are added: a tag with an inner VID 10
and a tag with an outer VID 4010. As the bridge port PVC1 is untagged member, the tag with the inner VID is
stripped off. In the downstream direction, the translation table is consulted to assign frames with VID 4010 to
VLAN A (VID 10).
For example, to accept only VLAN-tagged frames on bridge port 4, execute following command:
24 E-DOC-CTC-20080229-0004 v1.0
Chapter 6
Additionally, you can use following CLI command to prevent the Thomson Gateway from modifying the user
priority indication in the VLAN tag:
E-DOC-CTC-20080229-0004 v1.0
25
Chapter 7
Introduction
In this scenario, the Thomson Gateway is intended to forward the incoming VLAN-tagged Ethernet frames to
a single PVC. Based on the VLAN user priority available in the VLAN tag, high priority marked frames get
priority when sending out the frames on the PVC.
This scenario configures the Thomson Gateway as bridge with one PVC. Frames coming in on a local
interface are checked on VLAN user priority. This priority is mapped to an internal priority class. Taking this
internal priority class into account, the frames are sent out on the PVC.
Following illustration shows the VLAN user priority mapping to one PVC scenario:
Thomson Gateway DSLAM
A 5
A 2 A 2
B 3 B 7
C 1 C 2
B 7 A 5
B 3 PVC1
C 2
C 1
Mechanisms
To set up this scenario, we use following mechanisms:
Disabled VLAN awareness: Ethernet frames coming in on the Thomson Gateway have a VLAN tag in their
header. However, the VLAN ID should not be taken into account. If the Ethernet bridge is VLAN aware, we
have to define all VLANs that have to pass through the Thomson Gateway. Otherwise, unknown VLANs
are dropped.
Ingress classification: this mechanism ensures that an internal priority class is assigned to a received
frame. In this scenario, the classification criterion has to be the VLAN user priority value.
Priority queuing: even in bridging mode, we can make advantage of the powerful Thomson Gateway
IPQoS implementation. By enabling IPQoS on the used PVC, we enable the queuing mechanism, which is
active on ATM interface level. This queuing mechanism handles incoming frames according to their
internal priority class. This way, frames passing the bridge can be treated in the same way as packets that
come from the IPQoS framework.
26 E-DOC-CTC-20080229-0004 v1.0
Chapter 7
Configuration overview
You must perform following configuration steps to configure the Thomson Gateway for this scenario:
1 Define which PVC must be used by configuring an ATM interface.
2 Connect the ATM interface to the Ethernet bridge.
3 Define that the bridge is not VLAN aware.
4 Enable VLAN user priority mapping for incoming frames on the local interface.
5 Enable QoS on the PVC to activate priority queuing.
6 Save the configuration.
=>:saveall
To create, configure and connect an ATM interface on top of this phonebook entry, execute following CLI
commands:
E-DOC-CTC-20080229-0004 v1.0
27
Chapter 7
If necessary, disable the VLAN awareness of the Ethernet bridge executing following CLI command:
To verify the configuration of your bridge port, execute following CLI command:
28 E-DOC-CTC-20080229-0004 v1.0
Chapter 7
The mapping between the regenerated user priority and the internal priority class is fixed.
The mapping between the internal priority class and the IP QoS queue is fixed.
=>:saveall
Expected result
At this moment all frames containing a VLAN user priority indication are, priority-wise, bridged on one PVC.
At the ingress side, frames received on a bridge port are checked for their VLAN user priority. This user
priority is mapped to the regenerated user priority, which in its turn corresponds to an internal priority class.
For example, VLAN user priority 1 is mapped to regenerated user priority 0, which corresponds to internal
priority class 4.
At the egress side, the internal priority class of a frame determines which queue is used. For example, frames
with internal priority class 4 are put in the best-effort queue on PVC1.
E-DOC-CTC-20080229-0004 v1.0
29
Chapter 8
Introduction
In this scenario, the Thomson Gateway is intended to forward the incoming VLAN-tagged Ethernet frames to
a set of PVCs. Based on the ToS byte in the header of IP packets in the frames, it is decided to which PVC the
frame must be forwarded.
This scenario configures the Thomson Gateway as bridge with three PVCs. Frames coming in on a local
interface are checked on the ToS byte in the IP header. This information is mapped to an internal priority
class. Taking this internal priority class into account, the frames are multiplexed over the three PVCs.
Following illustration shows the IP ToS mapping for ATM multiplexing scenario:
7 5
5
2 PVC1
7
3
3
PVC2
2
1 2 1
2
PVC3
Mechanisms
To set up this scenario, we use following mechanisms:
Disabled VLAN awareness: Ethernet frames coming in on the Thomson Gateway have a VLAN tag in their
header. However, neither the VLAN ID nor the VLAN user priority indication should be taken into account.
If the Ethernet bridge is VLAN aware, we have to define all VLANs that have to pass through the Thomson
Gateway. Otherwise, unknown VLANs are dropped.
Ingress classification: this mechanism ensures that an internal priority class is assigned to a received
frame. In this scenario, the classification criterion has to be the IP precedence field in the header of an IP
packet.
ATM interface bundles: this mechanism makes it possible to forward frames over multiple PVCs based on
the internal priority class assigned to each frame. Therefore, the priority mapping policy must be used to
configure a priority range for each PVC.
30 E-DOC-CTC-20080229-0004 v1.0
Chapter 8
Configuration overview
You must perform following configuration steps to configure the Thomson Gateway for this scenario:
1 Define which PVCs must be used by configuring an ATM interface for each one of them.
2 Create an ATM interface bundle to enable traffic multiplexing on multiple PVCs.
3 Connect the ATM interface bundle to the Ethernet bridge.
4 Define that the bridge is not VLAN aware.
5 Enable IP TOS priority mapping for incoming frames on the local interfaces.
6 Save the configuration.
=>:saveall
E-DOC-CTC-20080229-0004 v1.0
31
Chapter 8
To create, configure and connect ATM interfaces on top of these phonebook entries, execute following CLI
commands:
To define which ATM interfaces are part of the ATM interface bundle, execute following CLI commands:
To define which range of the internal priority classes is related to which PVC, execute following CLI
commands:
32 E-DOC-CTC-20080229-0004 v1.0
Chapter 8
To verify your ATM interface bundle configuration, execute following CLI command:
If necessary, disable the VLAN awareness of the Ethernet bridge executing following CLI command:
E-DOC-CTC-20080229-0004 v1.0
33
Chapter 8
ipprec=precedence: in this case, the classification criterion is the IP precedence value in the header of an
IP packet.
Execute following CLI command to enable this:
To verify the configuration of your bridge port, execute following CLI command:
Another example could be to check the IP DSCP marking, but only increase the internal class if the IP priority
indicates a higher priority than the default port priority.
Execute following CLI command to enable this:
The precedence mapping table can be configured, the DSCP mapping table is fixed.
=>:saveall
Expected result
To display the IP precedence mapping table, execute following CLI command:
At this moment, all packets will be mapped onto one of the PVCs in the ATM-bundle, based upon the priority
indication of the IP header.
34 E-DOC-CTC-20080229-0004 v1.0
Chapter 8
At the ingress side, frames received on a bridge port are checked for their IP precedence value. This value is
mapped to an internal priority class. For example, IP precedence value 1 is mapped to internal priority class 7.
At the egress side, the internal priority class of a frame determines which PVC is used. For example, frames
with internal priority class 7 are sent out on PVC2.
E-DOC-CTC-20080229-0004 v1.0
35
Visit us at:
www.thomson-broadband.com
Coordinates:
Thomson Telecom
Prins Boudewijnlaan 47
B-2650 Edegem
Belgium
Copyright