Download Provisioning IP traffic across MAC based access networks of tree

PROVISIONING IP TRAFFIC ACROSS MAC BASED ACCESS NETWORKS OF TREE TOPOLOGY
N Leligou, C Matrakidis, J D Angelopoulos
National Technical University of Athens
ABSTRACT
A lot of effort is invested in the standardization of
packet oriented Passive Optical Networks (PON),
which seem to be the next step in access networks
moving fiber closer to the customer. Packet-oriented
PONs will offer an efficient way to transfer IP traffic
providing at the same time flexible Quality of Service
mechanisms to support a great variety of services. The
present paper investigates different ways to connect the
end users to their Internet Service providers across this
connectionless system. The main tool to achieve
connection provisioning is the mapping of IP addresses
to lower layer identifiers such as the PON Medium
Access Control (MAC) addresses in shared-medium
topologies. We present a mechanism for dynamic
binding IP and layer 2 addresses, which offers high
connection flexibility to both the customer and the
access system operator. The requirements that these
functions impose on the PON modules are also
considered.
INTRODUCTION
The demands for increased bandwidth in the access
network, for aggregation of services on single network
and for higher reach and fewer active elements in the
access network imply the need for novel access
architectures. For the time being, the standardized
ATM Passive Optical Network (APON) system that
shares 622 Mbit/s downstream and 155 Mbit/s
upstream bandwidth with up to 32 users (optionally 64)
with a reach of 20 km, is sufficient. However, novel
access systems with increased bandwidth and service
offering are imminent. An important drive for high
bandwidth is the need for full service access networks.
Operators want to have one network that can serve
voice, video and data services. Another trend is that
the network traffic becomes more and more packet
oriented and most of the revenue for an operator comes
from services requiring high quality and having low
operational costs. Therefore a generic packet aware
access network suited for ATM cells and native
Ethernet frames will allow efficient and cost effective
support of variable length packets, managed by a
Quality of Service (QoS) aware Medium Access
Control (MAC) protocol (see Marly et al. (1)).
The implementation of an optical access network
optimised for packet transmission at 1.25 Gbit/s (in
both downstream and upstream), that combines high
transmission efficiency with a guaranteed level of QoS
clearly represents a competitive opportunity. Such a
network relies on several key innovative solutions,
which span the whole system, both for the
implementation of the transmission principles and for
the physical implementation. When working at Gbit/s
with a mixture of real-time and non-real time data in an
IP dominated world, a novel approach to the data
transfer format and mechanisms becomes necessary.
Operators intend to offer flexible solutions to their
customers in order to achieve high revenues that justify
their investments. This flexibility includes the support
of a variety of services, potentially different charging
strategies for different QoS and the support of user
connectivity to several Internet Service Providers
(ISPs); Moreover, the interconnection of such a
network with both legacy and emerging packet centric
metro networks is an open issue, which may necessitate
the introduction of Multi-Protocol Label Switching
(MPLS) philosophy in the access domain. This is
expected to ease the inter-working with the metro
network because it solves the scaling problem in the
access network with an approach simpler than ATM
Semi-permanent Virtual Circuits (SVCs). A control
interface between metro and access network in line
with the dictates of the MPLS architecture can be
adopted to facilitate alignment with differentiated
services and the enforcement of Service Level
Agreements (SLAs).
For these new packet oriented systems, we investigate
the forwarding/routing inside and outwards of the PON
and the connection provisioning in order to identify the
requirements imposed on the packet format. Routing
inside the access system is usually performed based on
the systems MAC address, which is also true for a
PON. This address allows the discrimination between
the different branches of the tree and the forwarding of
the traffic up to the Optical Networking Unit (ONU).
In packet oriented PONs, where there are no ATM
connections, it is necessary to define how the ONU
will forward the traffic to the end users and how the
Optical Line Termination (OLT), residing at the headend, will forward the traffic to the correct interface
towards the metro network that will lead to the ISP to
which the user subscribes for the specific service. The
case where several ISPs can serve the same customer
and the packet should be forwarded to the right one
each time has to be covered to allow the user to be
connected to different ISPs offering higher flexibility.
It is not enough for the OLT to pass the user’s packet
to any IP router, which can of course forward them
to their destination IP address because the user must
have a subscription with the ISP who will undertake
the delivery to the destination while enforcing the
relevant SLA.
In legacy mesh topologies, routers are interconnected
using point-to-point links and specific topology
discovery protocols (e.g. RIP, OSPF) are executed in
order to construct their routing tables. These tables
provide a mapping between the possible IP
destination addresses and the output interfaces. In the
case of a metro ring or tree-shaped PON system, these
shared medium systems provide connectivity affected
by the MAC protocol and addresses, i.e. each
node/module is identified using the MAC address,
and packet transmission/reception decisions are based
on this address as well as the MAC protocol rules.
Consequently, the appropriate MAC address has to be
attached to each IP packet that is encapsulated in
layer 2 frames, imposing a need for mapping between
the destination IP address and the MAC address. The
issue of address mapping is important and as we
know in an Ethernet Local Area Network (LAN)
invoking the ARP protocol solves the problem. A
similar solution is also required in the PON.
As new layer 2 structures and functions are
investigated for the packet PONs, the appropriate
mechanisms have to be proposed to provide
connection management over a packet-oriented
system. A number of options regarding the end
system technology, networking protocol suite and the
OLT’s interconnection to the networking world exist.
This article intends to study these different
alternatives in order to identify the requirements
imposed on the PON system. The next section defines
the problem. A first option attempting to make the
PON system transparent to the rest of the network is
presented while next a dynamic solution, which
extends the classical Ethernet Address Resolution
Protocol to the PON is proposed. The relation of the
later to the MultiProtocol Label Switching is
discussed. In the final section, the solutions are
compared and conclusions are drawn.
CONNECTION MANAGEMENT AND
FORWARDING IN PACKET GIGABIT PONS
A lot of effort is put in the standardization of layer 2,
(the Transmission Convergence layer) by both the
IEEE 802.3 “Ethernet in the First Mile” task Force
and the Full Service Access Network organization,
which intend to provide input to ITU-T. Regardless of
the framing solution adopted in the TC layer of a
PON, the frame format is very likely to include an
address field (in both downstream and upstream
direction), which will be referred to as the PON Local
Address (PLA). In this section we investigate the
end-to-end connectivity problems and we will end up
defining the use of this address and the information
that will be coded in it.
Assuming that the PON is connected to an IP
network, the IP addresses of the PCs located beyond
the ONUs should be advertised to the adjacent
routers, so that the packets destined to them are
forwarded to the PON OLT. This action should be
undertaken by the OLT.
In the downstream direction, the OLT (see Figure 1)
is supposed to receive packets destined to the PCs
shown at the right side. To reach their destination,
packets have to reach first the proper ONU and
afterwards be forwarded to the correct T-interface
(the interface between the ONU and the user’s
device). To travel to the correct ONU, the appropriate
PON MAC address, which is not attached to the
incoming packet for any of the deployed metro
interfaces, has to be discovered and then attached at
the layer 2 packet. The OLT has no knowledge of
where the PC owning the packets’ destination IP
address resides and therefore to which ONU to
forward the packet by inserting the relevant PLA. If
the layer-3 protocol is IP, which is very likely, the
OLT has to map IP addresses to PON MAC
addresses. Even if the ISP encapsulates the IP packets
into Ethernet Frames attaching the Ethernet MAC
addresses of the PC NIC cards, the PON Local
Address is required for the Ethernet frame to reach
the proper ONU. In this case, it is the Ethernet MAC
address that has to be mapped to the PON Local
Address instead of the IP address. (From this point
on, even if the extension of Ethernet framing to the
PON access system is pursued mainly by IEEE
802.3ah, we will use the term “Ethernet MAC
address” to signify only the Ethernet LAN Ethernet
MAC addresses of the PC NIC cards located at the
user end systems.) In any case, the problem that arises
is the construction and maintenance of a table
mapping the PON MAC addresses to incoming layer
2 or layer 3 addresses, depending on the OLT
interface employed.
At the ONU similar problems exist. In case the ISP
does not prepare the Ethernet MAC frames, the ONU
has to attach the Ethernet MAC address of the NIC
cards, which further implies the introduction of
address mapping tables and the implementation of the
relevant mechanism for their construction and
maintenance. Even if the Ethernet MAC address is
known, the appropriate ONU interface has to be
defined.
In the upstream direction, the inverted function has to
be performed at the OLT. Packets traveling to the
OLT have to be forwarded to the correct interface. In
principle the PON MAC address identifies the ONU
and since one ONU may be connected to more than
one ISP, the PON MAC address is not the correct
information to base this decision on. Neither can the
IP address be employed, since the destination IP
address describes the destination device and not the
ISP. This would be equivalent to leaving a parcel in
T Interfaces
identified by the
PLA
Interfaces
identified by the
PLA
PON
ISP 1
4
ONU
IWU
Router
1
1
Home PC
Router2
OLT
ONU
Router3
Router 4
ISP 2
PLA k
PLA z
ONU 1
PLA x
ONU n
ONU 2
Figure 1: Transparent PON solution
the motorway with the destination address on it, in the
expectation that any lorry going to the destination will
pick it up and deliver it. In reality only the lorry,
which you have commissioned will carry it. The
parcel should be delivered at the mover’s premises. In
the data network case, the Internet Service Provider
has a contract to deliver your packets and has also
paid the long distance providers for their part of the
dispatch. So we need a connection provisioning tool
other than the IP address. The part of the OLT that
performs the address translation and the packet
adaptation to the possibly different metro network
layer 2 format plays the role of the PON –metro
InterWorking Unit (appearing in figures as IWU).
Up to this point, we have been referring only to
Passive Optical Networks although Hybrid Fiber
Coaxial (HFC) systems are also MAC based systems
of tree topology. HFC systems have already been
specified by DOCSIS (Plumer (2)), where
connections at a layer higher than the UDP are
established with the aid of the Trivial File Transfer
Protocol (Sollins (4)). Each cable modem, having
completed the ranging procedure, downloads a
configuration file from the head-end to get all the
necessary information for the communication with the
ISP. Different configuration files per modem may
exist. At the head-end, a DHCP server dynamically
assigns IP addresses to the modems and not to the
PCs attached. It is worth noting that in the HFC
system, the Network Termination equipment is
located inside the buildings, which is not the case for
the PON, where all Fiber To The Home, Fiber To The
Building and Fiber To The Cabinet cases are
investigated. In case the ONU is located in an SME’s
premises, then the SME may use a PC with the
necessary software to route the incoming traffic. In
contrast, when the ONU is located in the cabinet, then
the size and the protection of the device become of
great importance.
Several solutions are provided for other access
technologies: In POTS modem, this function is
performed using the telephone number, based on
which a circuit is established. Changing the telephone
number that the modem calls, connection to different
ISPs is possible. In ADSL technology, ATM
mechanisms are available to establish connections
based on the VCI/VPI fields. It is possible to
provision these connections assigning a certain set of
values to each customer that signs a contract. Another
option for packet-oriented systems is the use of the
Point to Point Protocol (PPP) which is designed for
simple links which transport packets between two
peers. The PPP provides the Link Control Protocol
and the Network Control Protocol. The former
defines also messages for the authentication of the
user and for connection establishment between the
two peers. In packet based PON case, where
minimization of the overhead and inefficiency is
important, the encapsulation of IP packets in multiple
layer data units should be avoided and therefore the
use of PPP is not recommended.
STRAIGHTFORWARD SOLUTION: IP
TRANSPARENT PON
In legacy mesh topologies, point to point links are
used to connect the routers and they exchange routing
information using topology discovery protocols (i.e.
RIP, OSPF). It is tempting to try to make the PON
system transparent emulating point to point links:
routers not belonging to the PON consider their
output ports acting exactly as they always do
performing routing protocols. This means that in
Figure 1 router 1 will consider its output ports
connected to routers 2,3 and 4 and executes wellknown routing protocols such as RIP and OSPF or
any other. To let this happen, the OLT assumes a oneto-one correspondence between its input interfaces
and each ONU (hence the corresponding PON MAC
address). So, one output port of router 1 is needed for
each ONU (which is a disadvantage). The OLT then
needs no mapping table since each interface maps to
one ONU address PLA. So, the same destination PON
MAC address will be attached to all the packets
coming from the same input interface. This situation
is shown in Figure 1 with the dotted lines. The routers
can exchange routing table information without
awareness of the PON’s existence.
This means that the front end of the OLT must
function as an InterWorking Unit, which will process
IP packets and map IP addresses to PON MAC
addresses (PLAs) according to the input port in which
they appear. When a new router is set-up and intends
to use the PON system to reach other routers, the
PON system administrator is informed and the
InterWorking Unit is responsible for the attachment
of the PON Local address to the packets coming from
the specified interface so that the routers are
connected.
On the other side (T interface) the ONU has to
forward the IP packets to the routers. If we extend the
PON Local address to cover the T-interfaces as well,
then the ONU is able to forward the packets based on
the PLA, avoiding IP layer processing. The mapping
of T-interfaces to PLA’s can be configurable.
The end result of the above architectural solution is
that, from the point of view of the routers, the PON
appears as a mesh of logical connections and behind
each port they find another router. They can run RIP,
OSPF e.t.c. without any modification (transparent
PON). This is the same situation as if we had used
leased lines to connect the customer router to the
ports of the core edge router and is similar to the one
in the Digital Subscriber Line (DSL) case where
virtual circuits are established at the aid of the ATM
layer at subscription time. The great advantage is the
low processing required by the OLT and the ONU.
The OLT attaches the same label to every packet
coming from a V-Interface and the ONU forwards the
packet to the T-interface based only on the PLA
without proceeding to IP layer processing. These
relaxed processing requirements imply low
implementation cost.
Although the transparent PON solution is elegant in
theory because it completely avoids the need for the
PON to have any knowledge of IP addresses and
functions, it is not in practical terms a satisfactory
solution. The great disadvantage of this approach is
that it assumes a 1:1 relation between OLT ports and
end routers. As the total number of routers connected
at the ONUs may exceed one hundred for a PON
network with a split ratio of 64 (for which current
PON systems are designed) it is not cost effective to
use as many ports in the core edge router as PON
terminations (NTs). A dedicated port is only justified
for big customer premises, which have their own IP
network identifier (net_id) and constitute a Customer
Premises Network. (Before the PON installation may
have used leased lines). Another drawback is that it
assumes that the ONU is connected to routers or PC
equipped with the respective functionality, which is
not necessarily true for residential users, who cannot
be assumed to run the appropriate route discovery
protocols adopted in the autonomous domain
belonging to the ISP.
DYNAMIC SOLUTION: GPON ARP
To make the PON system more flexible and, thus an
attractive access solution, we introduce a dynamic
address resolution mechanism, which we will
describe in reference to figure 2, where the complete
situation when the metro network is also brought into
the picture can be seen. The OLT is connected to the
metro network via a metro node which can be an
SDH Add Drop Multiplexer (ADM) or a Resilient
Packet Ring (RPR (5)) ADM or any other metro
network node. Semi-permanent connections are
assumed set up from the OLT to the ISP gateways.
The dynamic PON address resolution mechanism we
propose, leads to a self-learning plug and play system
and it follows the philosophy of ARP, which is a
classic protocol for binding IP and Ethernet MAC
addresses. Whenever an IP packet arrives to the OLT,
the OLT broadcasts a “GPON ARP” message
containing the destination IP address and requesting
the Ethernet MAC address of the PC network card
and indirectly soliciting the PLA as well. The ONUs
in turn broadcast the ARP message. The PC owning
the destination IP address responds with its Ethernet
MAC address. When the response reaches the ONU,
the later updates its forwarding table adding the T
interface – PLA pair and forwards the response to the
OLT attaching the PLA field. When the response
arrives at the OLT, this matches the IP to the PLA.
This implies that a field to accommodate the PLA has
to be foreseen in the TC-layer frame format of the
packet Gigabit PON. (Note that if the PLA identifies
the “granting” entity, either the ONU or the T
interface, according to what the PON system
designers specify, there would not be the need to add
the PLA in the upstream frame format, since the OLT
would deduce the PLA from the grant that caused the
transmission of the PON ARP message response.)
Gateway
of ISP 1
(SDH,
RPR)
ADM
Provisioned
Connections
identified by the
PLA
Interfaces
identified
by the PLA
Home
PC
(SDH,
RPR)
PON
(SDH,
RPR)
1
ADM
4
IWU
ONU
ADM
OLT
ONU
(SDH,
RPR)
Router 3
ADM
Gateway
of ISP 2
Router 2
Router 4
PLA k
ONU 1
PLA x
ONU n
Mapping of I/Fs
to ISP connections
Figure 2: Managing connections across the PON and metro
To manage the address mapping tables, the OLT
should maintain a cache with IP-PLA pairs, which
can be updated using a self-learning approach, similar
to the one found in Ethernet bridges i.e. monitor
upstream packets and note IP PLA pairs. For easy
reconfiguration, the entries will expire automatically
every few minutes. So only occasionally, when an
entry cannot be found in the cache, will broadcasting
be necessary. Several options regarding the fields that
will code these messages exist but are beyond the
scope of this article.
Turning our attention to the upstream direction, we
may assume that the OLT is connected to different
ISPs via different V-interfaces from the OLT to the
metro network whose translation depends on the kind
of metro the OLT is attached to. Since, as described
in the previous section, the destination IP address of
the packet is not enough to designate the ISP that will
undertake the packet delivery, it is necessary to set a
function that maps the PLA to the V interfaces. If we
assume that each home is provided with a different
interface in the ONU for each ISP, then the situation
is simple since the ONU will insert the appropriate
PLA depending on the T interface –ISP association
configured at subscription time. In other words, part
of the PLA will indicate the V interface that has to be
used to drive the packets from users to the appropriate
ISPs.
This solution seems to be far from the perfect since
the user should be able to configure his PC to connect
to any ISP he wishes without requesting a separate
interface from the operator. Clearly, a provisioning
tool (an address field above the MAC) is needed to
cover this case. The nearest standardized solution is to
use the Link Layer Control (LLC) address or the
Virtual LAN (VLAN) address fields (IEEE (3)). If the
4K different VLAN identifiers are not considered to
be enough to cover all the possible virtual subnetworks, it may prove necessary to adopt a new
extended field in the LLC layer. The user will set the
required VLAN address in his terminal that will allow
his traffic to be switched to the ISP’s gateway very
much the same way this can be done using the
VCI/VPI field in ADSL modems. The OLT will then
remove the PON framing and forward the Ethernet
packet. The ISP will be able to configure VLANs
covering all their subscribing customers in the PON.
Alternatively, the PLA can be extended to cover the
different V interfaces transferring the VLAN tag
processing function from the OLT to the ONU,
increasing at the same time the width of the PLA. In
any case, user connectivity to more than one ISP
using a single interface is backed. An indirect
conclusion is that PPP as used in ADSL and POTs
modems does not seem useful anymore since its role
will be played by LLC (or extended LLC). The single
byte address field it possesses is not enough to carry
out provisioning in the PON. This field is not used
anyway even in modems, being in fact suppressed for
increased efficiency, since it is there for legacy
reasons.
PON ARP AND MPLS
An important case that hasn't been discussed yet is the
one where MPLS is employed in the metro network
leading to the important question of where the MPLS
will be terminated in such a network. It can either
terminate at the OLT, at the ONU, or in special cases
it can even extend to the customer’s network. Our
opinion is that in such a case the MPLS architecture
should extend at least to the ONU, since it allows the
viewing of the PON as an integral part of the network,
and its management as such. We can achieve that
employing mechanisms and tools similar to the ones
specified by MPLS.
Although we introduced our solution as GPON ARP,
it directly maps both to the philosophy and the
mechanisms of MPLS. To be more precise, the
solution we presented is the convergence of MPLS
and ARP since it extends MPLS from WAN and
metro networks to the access system and Ethernet
ARP from LAN to access. The PLA can double as a
label, with the OLT doing the necessary translations
to metro MPLS labels, and the ONU acting as an edge
router, classifying traffic into “Forwarding Equivalent
Classes” of MPLS. The basis for this classification
may be the destination ISP, or the Quality of service
or both. As a result, attaching the PON to a metro
MPLS network, the management of the metro
network can also incorporate the management of the
PON. This solution could also be extended to allow
MPLS to reach into customer networks as well,
however such a case is considered unlikely within the
market segment where PONs are currently targeted
and is not considered further.
One possible disadvantage of this set up is at the
ONU acting as an edge router, requiring higher
complexity. However, the one-to-many nature of the
PON and the mechanism of the PON ARP allows the
OLT to perform the tasks of the edge router instead of
the ONU while the PON appears externally (from
both sides) as part of the MPLS network.
CONCLUSIONS
We have addressed the problem of connection
provisioning across a Gigabit packet-oriented PON.
The attempt to make the PON transparent led to a
system that emulates provisioned circuits, which is
not suitable for packet based full service access
networks that intend to reach residential customers.
This led to the introduction of a mechanism that
dynamically binds layer 2 PON addresses to IP
addresses (or LAN Ethernet addresses when the ISP
encapsulates the traffic in LAN Ethernet frames). The
mapping tables are constructed and maintained at the
OLT exploiting a protocol similar to Ethernet ARP
and the self-learning practice of Ethernet bridges (i.e.
monitoring upstream traffic and noting IP source
versus PLA). Broadcasting the ARP message by the
OLT, in the fashion used by a Customer Premises
Network gateway, completes the method whenever an
entry is not already in place in the mapping table.
The introduction of such a dynamic IP-PLA
resolution mechanism allows the packet oriented
access system to support: different technology enddevices (which may for example be routers in case of
an SME or PCs in case of residential users) or even
different technology T-interfaces, and high flexibility
in user connectivity, allowing it to be connected to
different ISPs, which will make the PON more
attractive than other existing access technologies.
Although this solution increases the complexity of the
ONU and the OLT, it is considered necessary for a
gigabit packet PON that targets deployment in the
near future. The same end result could alternatively
be achieved by implementing “connections” at higher
layers, which however would impose tighter per
packet processing requirements at the PON modules.
ACKNOWLEDGEMENT
The work presented in this paper was partially funded
by the EU project IST-2001-34523 “GIANT”.
REFERENCES
1.
Nick Marly, John Angelopoulos, Paolo
Solina, Xing-Zhi Qiu, Simon Fisher, Edgard Laes,
2002, Network and Optical Communications
conference proceedings, “The IST-GIANT Project
(GIgaPON Access NeTwork)”, Darmstadt, Germany.
2.
David Plumer, Network Working Group of
ITU RFC 826 “An Ethernet address Resolution
Protocol”.
3.
IEEE 802.1Q, 1997, “Draft Standard for
Virtual Bridge Local Area Networks,'' P802.1Q/D1,
May 16.
4.
K. Sollins, 1992, ITU-T RFC 1350 “THE
TFTP PROTOCOL”.
5.
Resilient
Packet
Ring
task
force,
http://www.ieee.802.17.