Design Implementation of IPv6 services over GMPLS based IP/Optical Network
Mallik Tatipamula and Francois Le Faucheur, Cisco Systems
Tomohiro Otani, KDDI
Hiroshi Esaki, University of Tokyo

ABSTRACTIn recent days, there has been considerable interest in
deploying IPv6 based services. Trial and commercial IPv6
services [1, 2] offering has already begun, especially in Japan,
Korea, China and other parts of the world. At the same time,
many service providers have embraced Multi-Protocol Label
Switching (MPLS) as the enabler for the required multiservice
capabilities of their next generation packet network. Also, thewidespread deployment of DWDM based optical transportsystems in the core network to satisfy the tremendous need andincrease in capacity demand, has led network planners toreconsider traditional approaches to “provisioning” and “network
restoration” and plan integration of the optical layer into the
MPLS infrastructure according to the emerging GMPLS
technology. The purpose of this paper is to discuss next
generation network architecture evolution and present a detailedarchitecture for transport of emerging IPv6 services andapplications over next generation GMPLS multi-service
backbone network. This paper also presents an implementationand demonstration of a new technique for IPv6 transport over
GMPLS backbone network as well as interoperability
verification of IPv6 and GMPLS using a GMPLS network test
bed.

INTRODUCTION
The current IP address space is unable to satisfy thepotentially huge increase in the number of users or thegeographical needs of the Internet expansion, let alone therequirements of emerging applications and services such as
Internet-enabled personal digital assistants (PDAs), homearea networks (HANs), Internet-connected transportation(for example, automobiles), integrated IP telephonyservices, IP wireless services, and distributed gaming. IPv6
is designed to meet these requirements and allow a return
to a global environment where the addressing rules of the
network are again transparent to the applications. A
number of service providers [1, 2] in Japan have alreadystarted offering trial and commercial IPv6 services. Also
several National Research Networks around the worldconsider IPv6 as a key technology for their next generation
networks.

At the same time, many service providers haveselected MPLS as the fundamental technology for theirnext generation packet network. A prime driver for thisevolution is MPLS multiservice capability, which enables
network operators to cope with the broadening of the IPv4
service offering (such as IPv4 VPN services) and at thesame time allow many other services, which were so far
supported on multiple technology specific networks, to be
migrated to a single infrastructure. Examples of suchservices currently being migrated onto the MPLS
multiservice infrastructure include ATM services, Frame
Relay services, Ethernet services and PSTN.
Finally, the widespread deployment of DWDM based
optical transport systems in the core network to satisfy thecorresponding increase in capacity demand, has led service
providers to reconsider traditional approaches to“provisioning” and “network restoration”. Consequently,
they are considering, or are already planning, to push theinfrastructure integration paradigm one step further byintegrating the optical layer into the MPLS Control Plane
based on the emerging Generalized Multi-Protocol Label
Switching (GMPLS) technology [3]. GMPLS has emerged
as a next generation networking protocol for providing an
intelligent optical control plane for optical networks.
GMPLS is considered to be a superset of MPLS, as it
extends the forwarding and control planes to include not
only packet based, cell based but also SONET, DWDM
and fiber based network elements
The emerging Grid, Supercomputing and Ubiquitous
applications and services, traffic growth and technologicaladvancements (such as GMPLS, IPv6, etc.) are different
forces that will drive the architecture and evolution of next
generation networks.
In this paper, we provide a brief introduction about
network evolution towards an intelligent multi-service
Optical network. A view of next generation networkarchitecture based on IPv6 and GMPLS technologies ispresented. We propose a specific method known as 6PE totransport new emerging IPv6 services and applications
over next generation GMPLS based multi-service
backbone networks. The detailed architecture of 6PE is
discussed and early trial demonstration as well asDesign Implementation of IPv6 services over GMPLS based IP/Optical Network

interoperability evaluation is presented. Finally a numberof conclusions are proposed.

NEXT GENERATION NETWORKEVOLUTION
EVOLUTION TOWARDS MULTI-SERVICEOPTICAL PACKET BACKBONE NETWORKThe global telecommunication system is being transformed
into a new network with a capacity many orders ofmagnitude greater than it used to be in early 1990s.
Traditional telecom backbone network architecture ismoving from a world of many separate backbone networks
for voice (e.g., PSTN), data (internet, Frame Relay, ATM),
radio and cable, into a world of a single high bandwidth
multi-service packet backbone network as shown in Fig. 1.

2

NEED FOR OPTICAL INTELLIGENCE IN
MULTI-SERVICE PACKET BACKBONENETWORKThe core routers in multiservice networks are connected toa long haul DWDM network as shown in Fig. 2. Today’s
DWDM network configurations are static using
Element/Network Management Systems (EMSs/NMSs) as
shown in Fig. 2a. Establishing a connection is a process
involving many steps, which can take several months. The
process is initiated by a series of administrative tasks torequest the service that results in core networks becoming
increasingly difficult to operate.
An intelligent Optical Control Plane based on GMPLS
provides the ability to automate many of the optical
network functions that are directly related to theoperational complexities. These functions include rapid
provisioning of bandwidth, service velocity, and automatic
resource discovery. Traffic engineering parameters relating
to optical protection support, available bandwidth, route
diversity and quality of service, are distributed throughout
the network allowing every node in the network to havefull visibility and configuration status of every other node
– ultimately making the optical network intelligent.
Therefore, as service providers introduce new network
elements into their networks, add/remove facilities, or turnup new circuits, the control plane will automatically
distribute and update the network with the new
information. The contrast today is that many of these
upgrades and updates are performed manually and areoperationally intensive. These features offered by an
intelligent optical control plane are key for next generation
multi-service backbone networks.

Figure 1. Network evolution from multi-tiered backbone network
to a single multi-service packet backbone network

The packet switched backbone that can handle andscale a wide variety of services is a key component in any
multi-service backbone network. It should be able to carrydifferent types of traffic that have diverse characteristics,
e.g.,- Real-time traffic- Internet traffic- Enterprise communications- Voice and video streaming
Such backbone networks must deliver true, carrierclass resilience and serviceability, and support powerful IP
border routing for peering with other IP networks. This
type of multiservice packet backbone consists of routers
running the MPLS protocol suite.

Fig. 2aFig. 2b

Figure 2. Evolution towards next generation GMPLS basedIntelligent Multi-service Backbone network

Fig. 2b shows a next generation backbone comprisingcore routers connected with Intelligent Optical transport3

consisting of Optical Cross connects with GMPLS control
plane. Using a simple, network management system(NMS) based, point-and-click provisioning mechanism,
core router will first signal a request for an LSP and, upon
confirmation, dynamically set up the requested light pathacross the backbone network [4]. This is also known as apeer model, as OXC with GMPLS control plane acts asLabeled Switched Router, as discussed in next section.

GMPLS
GMPLS [3] has evolved from MPLS - the original IETF
standard intended to enhance the forwarding performanceand traffic engineering intelligence of packet-based (ATM,IP) networks. GMPLS extends these switch capabilities sothat it is not only packet switch capable (PSC), but also
Time Division Multiplex capable (TDM), Fiber Switch
Capable (FSC) and Lambda Switch Capable (LSC). In
other words, MPLS is supported mainly by routers anddata switches, however GMPLS can be supported by avariety of optical platforms including SONET ADMs,
Optical Cross-connects (OXCs) and DWDM systems asshown in Fig. 3. This will allow an entire infrastructure,extending from routers to the OXCs, to utilize a common
unified control plane based on GMPLS technology.
Regarding connection set up, while MPLS requires a
Label Switched Path (LSP) between two end point devices,
GMPLS extends this concept beyond simple point-to-pointconnections. In a GMPLS network it is possible to find andprovision end-to-end paths that traverse different networks
including optical domains with GMPLS control plane. Fig.
3 shows an example for the comparison of MPLS based
LSR (Label Switched Router) and GMPLS based OXC,
where Label could represent a Lambda or wavelength, as
the incoming IP traffic from core router can be mapped
directly into individual wavelengths (that are generally
known as labels).

Figure 3. Comparison between LSR and OXC with GMPLS
control plane

A VIEW OF NEXT GENERATIONNETWORK ARCHITECTURE
The emerging applications fueling demand for addresses
include Internet appliances, Internet enabled wirelessdevices such as PDAs, home area networks, integrated
telephony services, and net connected automobiles. In
particular, “always on” environments for devices andapplications that must be reachable by communication
initiated externally, for example, as well as the shift inresidential internet access to use broadband technologies
such as DSL, cable modem or Ethernet-to-the-Home,
preclude address conservation techniques such as IP
address pooling/leasing. Also, the anticipated rollout of
wireless data services is identified as a key IPv6 driver;this is reflected in the fact that the relevant industry
standardization bodies, e.g., the 3rd Generation Partnership
Universal
MobileProject(www.3gpp.org),
Telecommunication System (UMTS), and Mobile WirelessInternet Forum (MWIF), consider IPv6 as the foundation[5][6] for the future mobile/wireless IP services.
Aside from these applications that extend the Internet’s
functionality for existing users, consideration must be
given to the global population and the considerable
requirements that for example, highly populous nations arestarting to place on current Internet addressing.
Numerous network operators/service providers,
especially in Japan [1, 2], have already started offering
native IPv6 trials or commercial IPv6 services over their
Broadband access networks such as DSL, Cable, Metro
Ethernet, and 3G Wireless. Fig. 4 depicts the view of next
generation network Architecture [7] with common
multiservice backbone infrastructure supporting multiple
broadband dual stack (IPv4/IPv6) based accesstechnologies.

Figure 4. A view on Next Generation Multi-service Packet
Backbone network architecture with dual stack (IPv4-IPv6)
broadband access networks

Design Implementation of IPv6 services over GMPLS based IP/Optical Network

IPv6 DEPLOYMENT CONSIDERATIONS
Service providers running a GMPLS backbone alreadysupporting multiple services may wish to add IPv6 services
as well to their current service portfolio. However, thisenhancement must satisfy a number of requirements, suchas:
 The core network should not be impacted (i.e., nosoftware upgrade, no hardware upgrade, noconfiguration change, no change in operations) sothat the current stable and robust GMPLS coreshould not be put in jeopardy. Network stability
and smooth migration with minimal impact on
recently deployed or next generation backbone
networks are key requirements for service
providers/network operators as discussed in [8].
 Deployment should be scalable, so that norestrictions are imposed on the IPv6 services
neither in terms of performance nor in terms ofaddressing, nor should extensive “tunnel”
configuration be required.
Fig. 4 describes a view of next generation networkarchitecture, offering IPv6 services in various accessnetworks including 3G wireless (as described by 3GPP[5]) over a GMPLS based multi-service backbone network.
Considering this next generation network architecture, thenext section looks at how emerging IPv6 services can betransported over a GMPLS based Optical controlled
network. The next section discusses the detailed design
analysis for the “IPv6 Provider Edge Router over GMPLS”
approach (referred as 6PE in rest of the paper) for IPv6
integration seamlessly into the multi-service Optical packet
backbone networks based on GMPLS. Using 6PE, network
operators can leverage GMPLS backbone network foroffering IPv6 services over their access networks, meeting
the requirements discussed above and in particular without
any impact to their GMPLS backbone.

4

destination IPv6 network using the GMPLS infrastructurein the core. Inside the GMPLS core (P Routers), allcontrol protocols, including label distribution and Interior
Gateway Protocols (IGPs) remain IPv4 based. OXCs (withGMPLS control plane) act as P routers inside the core, andthey also remain purely IPv4 aware.
IPv6 over (GMPLS Data Plane + IPv6 Control
Plane): In the GMPLS core, although forwarding remains
IPv6-unaware (i.e. forwarding is purely label switching),
the control plane protocols (IGP and label distribution) are
IPv6 based protocols. This requires all edge (PE) and allcore (P) routers to support dual stack (IPv4-IPv6), as it
includes an IPv6 control plane.
This paper focuses exclusively on the first scheme
relying on 6PEs at the edge of the GMPLS based opticalcontrolled network since only this approach satisfies theoperational requirements, as mentioned in IPv6
deployment considerations section, to not impact the
GMPLS core. The following section provides detailed
description on the 6PE architecture and procedures fortransporting IPv6 over the GMPLS backbone.

6PE NETWORK ARCHITECTURE OVERVIEW
6PE enables IPv6 network islands to communicate witheach other over Multi-service GMPLS based opticalcontrolled backbone network using GMPLS LSPs (Label
Switched Path) as shown in Fig. 5. The method relies on
Multi-Protocol BGP extensions [9-11] for Provider Edge
Routers (6PE) to exchange IPv6 reachability information
along with a GMPLS label for each IPv6 address prefixannounced. 6PE routers are dual-stack (IPv4 and IPv6).

IPv6 SERVICES OVER GMPLS
BASED OPTICAL CONTROLLEDNETWORKIPv6 services over a GMPLS based Optical Controlled
network can conceptually be supported in two different
ways:

Figure 5. Logical view of 6PE connecting IPv6 islands over
GMPLS backbone

IPv6 over (GMPLS Data Plane + IPv4-only
Control Plane): In this scheme, only PE routers (i.e.,routers at the edge of the GMPLS cloud) need to support
IPv6. The PE routers run a dual stack – IPv4 and IPv6.
Such a PE is referred to as a 6PE. The IPv6 traffic
received from the IPv6 network is transported towards the

In line with the GMPLS based optical networkarchitecture described earlier, the 6PE approach relies on ahierarchy of labels imposed at the 6PE ingress router. The
top label provides PE-to-PE connectivity inside the
GMPLS backbone network: LDP (Label Distribution
Protocol) or RSVP-TE (Traffic Engineering extensions to5

ReSource ReserVation Protocol) distributes this label(referred to as the “top label”). The next label (referred toas the “bottom label”) is used by the 6PE egress router forIPv6 forwarding: it is distributed by MP-BGP (Multiprotocol BGP) in the “IPv6+label” address family.
Four types of routing interactions can be found on
the path between IPv6 end devices, host A to host B, as
shown in Fig. 6. Following steps are indicated as 1, 2, 3
and 4 in Fig. 6:

forwarding IPv6 traffic to customers connected to
6PE1.
4. GMPLS network, running an IPv4 Internal Gateway
Protocol (OSPF or IS-IS) to establish reachability between
6PEs and an IPv4 label distribution protocol (LDP, TDP,
RSVP) to distribute IPv4 labels.

1. Host A and host B, running IPv6 application and IPv6
stack, is attached to Customer Edge (CE) Router (CE1 andCE2 correspondingly), in IPv6 cloud. IPv6 cloud isrunning an IPv6 Interior Gateway Protocol (IGP such as
RIPng, IS-ISv6, OSPFv3).
2. IPv6 Customer Edge (CE) and 6PE routers exchanging
IPv6 routing information through an IPv6 External
Gateway Protocol (MP-BGP), Interior Gateway Protocol(IGP) or using static routes.


The CE1 advertises the site IPv6 prefix of host A
to 6PE1 using IGPv6, MP-BGP or static routes.
The CE2 learns the IPv6 address prefix of host A
from 6PE2 using IGPv6, MP-BGP or static
routes.

3. 6PE routers (6PE1 and 6PE2) peering together through
MP-BGP4 (or via a BGP Route Reflector) for exchanging
IPv6 reachability over the GMPLS network andperforming IPv6 forwarding.


6PE1 router announces its attached customers
IPv6 prefix reachability to 6PE2 on the network
using Multi-Protocol BGP extensions.
IPv6 address prefix of the customer site (of hostA) and corresponding label mapping (associatedto IPv6 address prefix) is carried as a part of the
Network Layer Reachability Information (NLRI)
in the multi-protocol BGP extensions attributes[10, 11].
Since the provider backbone is IPv4 only, the“NEXT_HOP” [11] attribute in the announcement
must include the IPv4 address of the announcing
router, 6PE1. Because MP-BGP requires that the
BGP next hop be of the same address family as“NLRI” in the multi-protocol extensions
attributes, this IPv4 address of 6PE1 needs to be
encoded into an IPv4 mapped IPv6 address [12].
This allows 6PE2 router to automatically learn the
IPv4 address of 6PE1 and thus impose thecorresponding MPLS IPv4 top label when

Figure 6. 6PE Routing and Control Plane interactions for host
B to learn routes to host A

IPv6 hosts, IPv6 routers in the IPv6 cloud and IPv6
CE routers are not aware that IPv6 packet forwarding
occurs over GMPLS clouds. They operate in their regular
IPv6 way. Similarly, P devices (be they P routers or
OXCs) inside the GMPLS network are not aware that they
are switching IPv6 packets, as they only use GMPLS
forwarding, LDP or RSVP-TE for binding IPv4 labels andan IPv4 Interior Gateway Protocol (OSPF or IS-IS) toestablish internal reachability inside the GMPLS cloud.
Therefore, the 6PE feature does not impact these GMPLS
core devices such as P routers, OXCs (acting as P routers),
nor IPv6 hosts or IPv6 CE routers. Only the PE devices
that actually connect IPv6 users need to be upgraded tosupport the 6PE functionality. Since forwarding in the corerelies on regular IPv4 based GMPLS label switching, line
rate performance is inherently available for IPv6 traffic as
well. The 6PE approach is very scalable for the service
provider since it does not require any tunnel provisioningor any configuration on a per-CE pair basis for CEs
requiring communication (which “IPv6 over IPv4
tunneling” approaches involve): connecting a new CE only
involves provisioning on the PE connecting this CE - thisis sufficient for that CE to automatically obtain global
reachability with all other CEs.

6PE CONTROL PLANE PROCEDURECES
From the Control Plane perspective, the main principles ofthis method are:

Design Implementation of IPv6 services over GMPLS based IP/Optical Network

6

1.

The 6PE BGP routers are dual-stack (IPv6 andIPv4) and have a regular “IPv4 address” for peer
communication through the IPv4 core.

support of [10] are presented below with some
implementation choices where appropriate:

2.

Multiprotocol iBGP is used between 6PEs toexchange IPv6 reachability information. Thus,
6PE2 learns BGP Next Hop address of 6PE1 (asshown in Fig. 6) to reach a destination IPv6
subnet of host A. The BGP protocol encoding
rules impose that this BGP Next Hop address be
encoded as an IPv6 address. However, 6PE1
needs to convey its IPv4 address (192.168.99.1).
Thus, 6PE1 actually embeds its IPv4 address inanIPv4-mapped
IPv6
address(::ffff:192.168.99.1) and includes this in the BGP“Next Hop” field.

NLRI Format
The label binding information is piggybacked along theprefix advertisement in the same MP_REACH_NLRI
attribute. The fact that the MP_REACH_NLRI contains alabel is indicated by SAFI (Sub-Address Family) value of
4.

3.

4.

5.

In order to resolve the recursion for an IPv6
destination subnet of host A, 6PE2 first converts
the BGP next hop IPv6 address with an embedded
IPv4 into an IPv4 address. Then 6PE2 resolves
this IPv4 address using the IPv4 Forwarding
Information Base (FIB) which provides the
GMPLS label of the LSP that can be used toreach the 6PE1. We will refer to this label as the"IPv4 label". The IPv4 label has been populated
in the IPv4 FIB through regular IPv4 GMPLS
Control Plane procedures using IGPv4 and
LDPv4 (or RSVP-TEv4). This IPv4 label is thenstored as the top label along with the destination
IPv6 subnet address in the IPv6 forwarding tableof 6PE2.
Multiprotocol iBGP is used by 6PE1 to bind alabel to each advertised destination IPv6 prefix asshown in Fig. 6. We refer to this label as the"BGP IPv6 label". 6PE1 creates an entry in its
Label Forwarding Information Base (LFIB) for
every BGP IPv6 label that identifies how toforward the corresponding IPv6 packets (e.g.,
forwards towards CE1).
The BGP IPv6 label is stored in the IPv6
forwarding table of 6PE2 as the bottom label inthe entry for the destination IPv6 prefix of host A.

Multi-Protocol BGP extension for "Labeled IPv6"
Multi-Protocol BGP already supports the IPv6 addressfamily via the Multi-Protocol Reachable NLRI
(MP_REACH_NLRI) and Multi-Protocol Unreachable
NLRI (MP_UNREACH_NLRI) attributes.
6PE requires that Multi-Protocol BGP be further
extended to be able to bind a GMPLS label to the IPv6
route as per [10]. The main aspects of this extension for

The NLRI for labeled IPv6 routes (used in "NLRI"
field of MP_REACH_NLRI and in "Withdrawn Routes"
field of MP_UNREACH_NLRI) contains one or more
triple <Length, Label, Prefix>: Length: total length of the label plus prefix
 Label: carries one label, where:
Label value: 20 high order bits
Unused: 3 following bits set to zero
Bottom of stack bit: low order bit([9] Allows the Label field to carry multiple label
values (that correspond to a label stack) but the
6PE only uses a single label value per NLRI) Prefix: IPv6 prefix of destination
Withdrawing Routes and Binding
To withdraw a route and the associated binding, the BGP
speaker uses the Withdrawn Routes field of the
MP_UNREACH_NLRI attribute with a label value set to0x800000 (in the NLRI field).
Capability Negotiation
6PE extends BGP Capability Negotiation [14] forsupporting "IPv6+label" capability in the following way:






6PE advertises capability for "IPv6+label" to aneighbor when configured to do so for thisneighbor
6PE also advertises capability for "IPv6" (i.e.,
unlabelled IPv6 packets) since there is a separate
Capabilities Optional Parameters for each SAFI
(Subsequent Address Family Identifier)If a neighbor has advertised "IPv6+label"capability, the 6PE will advertise all IPv6 routes
as labeled routes
If a neighbor has NOT advertised "IPv6+label"capability but has advertised "IPv6" capability,
the 6PE advertises all IPv6 routes as IPv6
(unlabelled) routes to this neighbor. Note that if a
6PE receives unlabelled IPv6 routes, then the 6PE
does not resolve the recursion and marks theseprefixes as unreachable in the IPv6 routing table
so that packets to this destination get dropped andnot sent into the GMPLS cloud.

7

6PE FORWARDING PLANE PROCEDURES

6PE SUPPORT OF IPv6 VPN SERVICES

Packet forwarding can take place after the control planeactions are performed, and the routing table andforwarding table have been populated as described above.

In addition to IPv6 Global connectivity services (supported
as described so far), Service Providers need to offer IPv6
VPN services. The prime driver for such IPv6 VPN
services is the exact same need for isolation of end users
intranets as sought with IPv4 VPN services. The potential
use of non-global Site Local IPv6 Prefixes in enterprisenetworks is another driver for such IPv6 VPNs.

The main principles of the 6PE forwarding plane are:
1. As shown in Fig. 7, host B (attached to CE2 router)sends an IPv6 packet with destination IPv6 address prefix(2001:b00:ffff::) of host A.
2. Once 6PE2 router receives IPv6 packet from CE2, 6PE2
does a look up on IPv6 destination address prefix in the
IPv6 FIB. As a result of this lookup, 6PE2 imposes twolabels to the IPv6 packet and sends the packet to P2:
 The bottom label, Label 1 (L1), is the “BGP IPv6
label”, bound by MP-BGP to IPv6 destination
address prefix (2001:b00:ffff::), as explained insteps 4 and 5 in previous section.
As explained in step 3 of previous section, thetop label, Label 2 (L2), was bound by LDPv4(or-RSVP-TE)/IGPv4 to the IPv4 address of
BGP next hop to reach 6PE1 through the
GMPLS cloud.
3. P2, in turn, uses the top label, L2, when making its
forwarding decision and forwards packet to P1 inside the
GMPLS cloud. In other words, inside the GMPLS cloud,normal GMPLS label switching is used based on top IPv4label, L2.
4. Since P1 is the penultimate hop with respect to the LSP
associated with a route to 6PE1, P1 pops the top label, L2,
before sending the packet to 6PE1.
5. When 6PE1 receives the packet, the BGP IPv6 label,
L1, is used to do a lookup in the Label Forwarding
Information Base (LFIB) that instructs 6PE1 on how toforward the packet (e.g., forward towards CE1).
In

Host A

2 0 0 1 :b 0 0 :ffff/4 8

O u t

L 1

-

IPv6 Routing&Forwarding Table

A c tio n
P o p

R o u te19 2 . 16 8 . 9 9 . 1/ 3 2

6PE 1

5

In

L 3

IPv6 packet to
2 0 0 1 :b 0 0 :ffff::

O u t

4

-

Figure 7.

N e x t -H o p

M P-B G P l ab el 1 to
2 0 0 1 :b 0 0 :ffff::

L D P/ IG Pv4
l ab el 3 to 6PE 1

O X C

O X C

P2

P1

A c tio n
P o p

2 a

La b e lp .q .r .s(G)MPLS Backbone

1 9 2 . 1 68 . 9 9 . 1

M P-B G P l ab el 1 to
2 0 0 1 :b 0 0 :ffff::

N e x t -H o p: : F F F F : 19 2 . 16 8 . 9 9 . 1

IPv4 Routing & Forwarding Table

C E 1

IPv6 packet to
2 0 0 1 :b 0 0 :ffff::

R o u te2 0 0 1: b 0 0 : f f f f : : / 4 8

L2

L D P/ IG Pv4
l ab el 2 to 6PE 1

In

L 2

O u t
L 3

3

L1

Host B

2 0 0 1 :b 0 0 :d d d d /4 8

2 b

IPv6 packet to
2 0 0 1 :b 0 0 :ffff::
p. q . r . s

La b e l

6PE 2

M P-B G P l ab el 1 to
2 0 0 1 :b 0 0 :ffff::

C E 2
IPv6 packet to
2 0 0 1 :b 0 0 :ffff::

1

IPv6 packet to
2 0 0 1 :b 0 0 :ffff::A c tio n

Swap

IPv6 packet forwarding over GMPLS controlled
Optical network

Extensions to the 6PE approach are being
standardized in the IETF [13] for also supporting such
IPv6 VPN services. This can be seen as combining the“IPv6 handling” of the 6PE approach described above withthe “VPN handling” of BGP/MPLS IPv4 VPNs [3]. The
major extensions to the 6PE approach described above are:
 Use of a different address family in MP-BGP
advertisement, which is the labeled IPv6 VPN family(which allows disambiguation of non-global –andpotentially overlapping-IPv6 addresses across VPNs)
 Use of the “Virtual Routing Forwarding (VRF)”
concept of BGP/MPLS IPv4 VPNs [3] whereby each
VPN has a separate set of routing and forwarding
tables.
Again, when deploying such IPv6 VPN services, only
PE devices that actually connect IPv6 VPN services willneed to be upgraded. There will be no impact on the core.
End users will benefit from the exact same set of features
for IPv6 VPN services as for existing IPv4 VPN services
while Services Providers will benefit from the exact same
set of Operations, Administration and Maintenance (OAM)
tools across IPv4 VPN services and IPv6 VPN services.

INTEROPERABILITYEVALUATION
Multi-vendor interoperability in terms of GMPLS
functions as well as IPv6 transport over GMPLS wasevaluated. For this evaluation, an optical core network test
bed, consisting of two GMPLS enabled IP/MPLS routers
and two photonic cross connects (PXCs) using all-opticalthree dimensional micro electro-mechanical system (3DMEMS) switches, [15, 16] were used as shown in Fig. 8.
The two PXCs were connected by a Gigabit Ethernet(GbE) link, and each GMPLS router and PXC were also
connected by a GbE link.
Moreover, IPv4 addresses were assigned to interfacesof PXCs as well as routers in order to form GMPLS
traffic-engineering (TE) links between a pair of interfaces.
GMPLS OSPF-TE [17] information was exchanged using
an Ethernet based GMPLS out-of-band control plane(GMPLS c-plane), indicating link attributes with abandwidth of 1 Gb/s, the switching capability of lambda orDesign Implementation of IPv6 services over GMPLS based IP/Optical Network

packet, and the encoding type of Ethernet. The ingressrouter initiated a GMPLS RSVP-TE [18] path message ofa GMPLS LSP with 1 Gb/s bandwidth and Ethernet
encoding and received the reserve message generated fromthe egress router, and as a result, the GMPLS LSP was
successfully established via PXCs by a GMPLS out-ofband signaling mechanism. By using the created GMPLS
tunnel as indicated in Fig. 8, non-GMPLS OSPF
information came to be exchanged between routers by anin-band signaling mechanism and each router acquired afull routing adjacency.

8

networks. This paper first briefly discusses current
migration of carrier backbone networks toward a unified
multi-service GMPLS network infrastructure. A view ofsuch next generation network architecture is being
presented to efficiently support both IPv4 and IPv6 centric
data as well as multiservice traffic, with a common
multiservice GMPLS based optical backbone network forvarious broadband access networks including xDSL,
Cable, FTTH, Wireless etc. This paper describes thearchitecture and procedures associated with the 6PE (IPv6
Provider Edge) method for support of IPv6 services over
GMPLS backbone networks. The 6PE method is very
attractive to Service Providers migrating to multiservice
GMPLS based networks because it achieves full IPv6
reachability in a scalable way, without any impact on the
network core, and with line rate performance in the core.
Also, the 6PE method is being extended so that IPv6 VPN
services can also be added incrementally to the service
portfolio with the same set of features and operational
aspects as IPv4 VPNs.
REFERENCES

Figure 8. Interoperability Evaluation Test bed configuration
Since PXCs within the GMPLS network are only
IPv4 aware and only support IPv4 addresses, the 6PE
method was utilized to transport IPv6 packets, by allowing
GMPLS routers to be operated as an IPv6 edge. IPv6
addresses were assigned to the GbE interfaces connectedto the IPv6 traffic generators and iBGP session was
initiated over the GMPLS tunnel between GMPLS edge
routers. IPv6 packets encapsulated by the IPv4 MPLS
LDP label were successfully transported and confirmed by
the packet generating tests.
In this setup, IPv6 routing interoperability
between multi-vendor products was also evaluated. As
shown in Fig. 8, an IPv6 router from a different vendor
was attached to one of the GMPLS routers by a GbE link.
By running OSPFv3 between the IPv6 router and the
GMPLS router, they became an IPv6 routing adjacency,
and as a result, the IPv6 reachability through the GMPLS
tunnel could be confirmed from an IPv6 interface on the
IPv6 router to an IPv6 interface of another GMPLS router
by ICMP version 6. Thus, IPv6 and GMPLS
interoperability was experimentally confirmed.

CONCLUSIONS
Today service providers offer Voice, xDSL, Cable, Frame
Relay, ATM, Ethernet, wireless packet data and IP
services using an overlay of many different backbone[1] KDDI’s IPv6 offering:
http://www.ipv6style.jp/en/news/2003/0217_kddi.shtml[2] NTT’s IPv6 offering:
http://www.v6.ntt.net/globe/index_e.html.
[3] E. Rosen et al., “BGP/MPLS VPNs,” IETF draft, draft-ietfl3vpn-rfc2547bis-03.txt, Work in Progress.
[4] Eric Mannie, “Generalized Multi-Protocol Label SwitchingArchitecture,” IETF RFC3945.
[5] M. Wasserman et al., “Recommendations for IPv6 in 3GPP
standards,” IETF RFC3314.
[6] Juha Wiljakka, “Transition to IPv6 in GPRS and WCDMA
Mobile Networks,” IEEE Communication Magazine, April
2002.
[7] Mohamed El-Sayed and Jeffrey Jaffe, “A View of
Telecommunication
Network
Evolution,”IEEE
Communication Magazine, Dec. 2002.
[8] Daniel G. Waddington and Fangzhe Chang, “Realizing thetransition to IPv6,” IEEE Communication Magazine, June
2002.
[9] J. De Clercq, Francois Le Faucheur et al., “Connecting IPv6
islands across IPv4 Clouds with BGP,” IETF draft, draftooms-v6ops-bgp-tunnel-04.txt, Work in Progress.
[10] Y. Rekhter and E. Rosen, “Carrying Label Information in
BGP-4,” IETF RFC3107.
[11] T. Bates et al., “Multi-Protocol Extensions for BGP-4,”
IETF RFC2858.
[12] R. Hinden and S. Deering, “IP Version 6 Addressing
Architecture,” IETF draft, draft-ietf-ipv6-addr-arch-v401.txt, Work in Progress.
[13] J. De Clercq, Francois Le Faucheur et al., “BGP-MPLS IP
VPN extension for IPv6 VPN,” IETF draft, draft-ietf-l3vpnbgp-ipv6-05.txt, Work in Progress.
[14] R. Chandra et al., “Capabilities Advertisement with BGP4,” IETF RFC2482.

9[15] T. Otani, et al., “Field trial of GMPLS controlled PXCs and
IP/MPLS routers using existing network facilities,”
European conference on optical communications (ECOC)
2003, Paper Tu3.4.3, 2003.
[16] T. Otani, “Field Trial of GMPLS Controlled PXCs and
IP/MPLS Routers,” Opto-Electronics and Communications
Conference (OECC) 2004, paper 14B3-3, 2004.
[17] K. Kompela, et al, “OSPF extensions in support ofgeneralized MPLS,” IETF draft, draft-ietf-ccamp-ospfgmpls-extensions-09.txt, 2002, Work in Progress.
[18] L. Berger, et al, “Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions,”
IETF RFC3473.

BIOGRAPHIESMALLIK TATIPAMULA [SM] (mtatipam@cisco.com)
received B.Tech in Electronics and Communications Engineeringfrom Regional Engineering College, Warangal, India and M.
Tech in Communication Systems and High Frequency
Technologies from Indian Institute of Technology, Chennai(Madras), India. He is currently a senior technical leader foradvanced technologies in the Routing Technologies group at
Cisco Systems. His expertise include VoIP, mobile wireless,
optical networking, IPv6 and GMPLS technologies. He closely
works with Service Providers and National Research Networks
around the world in deploying these advanced technologies intheir next generation networks. He has been with Cisco since1998. Previously he worked at Motorola as a Principal Engineer,
responsible for design of next generation wireless networks.
From 1993-1997 he was with Nortel Networks, Ottawa as Senior
Member of Scientific Staff, worked on Nortel's Optical andwireless products. He has over 12 years of experience in Telecomand Networking Industry. He is a senior member of IEEE andhas served on technical program committees of several leading
IEEE and SPIE international conferences. He appeared on Who
is who in the world, Who is who in Engineering, Who is who in
America. He offers courses at various leading universities,
including a course on advanced Internet Protocols: Architectures,Standards and Applications at University of California, Berkeley
extn.
FRANCOIS Le FAUCHEUR is a system architect at Cisco
Systems working in product development in the areas of QoS and
MPLS. He has worked for several telecom carriers in France andAustralia on the development of enhanced services on ATM,
Frame Relay, SMDS, and IP. He has an engineering degree inreal-time data processing from the Ecole Centrale de Paris. Heedits and coauthors many IETF specifications in the areas of
MPLS and QoS, such as MPLS support of DifferentiatedServices, DiffServ-aware MPLS TE. He has also filed several
patents in the areas of MPLS and QoS.
TOMOHIRO OTANI received the B.E., M.E. and Ph.D.
degrees in electronic engineering from the University of Tokyo,
Tokyo, Japan, in 1992, 1994, 2002, and Professional
Engineering degree in electrical engineering from Columbia
University, New York, in 1998, respectively. He is currently asenior research engineer of KDDI R&D Laboratories, Inc. In

1994, he joined Submarine Cable Systems Dept. of KDDI
Corporation. In 1998, he became a research engineer of Optical
Network Group in KDDI R&D Laboratories Inc. His researchinterests have been intelligent optical networks. He received theYoung Engineering Award from the Institute of Electrical,
Information and Communication Engineers (IEICE) of Japan in
1999. He is a member of the IEICE.
HIROSHI ESAKI received the B.E. and M.E. degrees from
Kyushu University, Fukuoka, Japan, in 1985 and 1987,
respectively. And, he received Ph.D from University of Tokyo,
Japan, in 1998. In 1987, he joined Research and Development
Center, Toshiba Corporation, where he engaged in the researchof ATM systems. From 1998, he works for University of Tokyo
as an associate professor, and works for WIDE project as a board
member. He has been at Bellcore in New Jersey (USA) as aresidential researcher from 1990 to 1991, and has engaged in the
research on high speed computer communications. From 1994 to
1996, he has been at CTR (Center for Telecommunications
Research) of Columbia University in New York (USA) as avisiting scholar. He is currently interested in high speed internetarchitecture, including MPLS technology, mobile computing andIPv6.