Point-to-Multipoint VLAN path signaling demonstration onthe GMPLS controlled Ethernet test network

Kou Kikuta, Daisuke Ishii, Satoru Okamoto and Naoaki YamanakaKeio University, 3-14-1 Hiyoshi, Kouhoku, Yokohama, 223-8522, Japan

kikuta@yamanaka.ics.keio.ac.jp

Abstract: This paper provides the demonstration of GMPLS controlled Point-to-Multipoint Ether-net path establishment. The prototype RSVP-TE is extended for supporting peer and overlay modelnetworks. Detailed RSVP-TE signaling mechanisms, experimental results are discussed.c© 2009 Optical Society of America

OCIS codes: (060.4255) Networks, multicast; (060.4510) Optical communications

1. IntroductionEthernet has greatly succeeded in Local Area Network (LAN). A simple forwarding scheme of Ethernet facilitatedthe development of high-speed and cost-effective Ethernet equipments. Ethernet is now expanding from LAN toWide Area Network (WAN) as a carrier grade transport network [1]. The carrier grade Ethernet will replace legacytransport network technologies such as SONET/SDH. To develop the carrier grade Ethernet, introducing a controlplane technology which provides Traffic Engineering (TE) function is important. Generalized Multi-Protocol LabelSwitching (GMPLS) [2] becomes a popular solution to provide control plane functionalities to the transport networks.For Ethernet WAN, IETF CCAMP is now standardizing “GMPLS controlled Ethernet Label Switching” (GELS)[3]. GMPLS extensions for controlling Ethernet VLAN path is developing. Point-to-Point (P2P) Ethernet VLANpath provisioning for provider backbone bridge traffic engineering (PBB-TE) network is developed [4]. However,a detailed Point-to-Multi-Point (P2MP) path provisioning mechanism which is naturally supported by Ethernet isnot yet discussed. For supporting IP-TV and 4K digital cinema delivery on Ethernet WAN, providing P2MP layer-2Virtual Private Network (VPN) service is quite important. Therefore, it is a very important challenge to establish aP2MP path in GMPLS controlled Ethernet WAN.

In this paper, the detailed implementation of P2MP RSVP-TE signaling extension for Ethernet VLAN pathbased on IETF RFC 4875 [5] is described. RFC 4875 specifies the modified RSVP-TE messages and procedures forestablishing a P2MP path, however, the detailed signaling mechanism is not specified. Therefore, we determine thedetailed signaling procedures, implement to the prototype GMPLS controlled Ethernet system, experiment to establishP2MP VLAN paths on the test network. The results and detailed extensions are discussed.

2. Architecture of GMPLS controlled Ethernet supporting P2MP path signalingFigure 1 shows a basic network architecture of the GMPLS controlled Ethernet. This network can provides E-line(P2P path) and E-Tree (P2MP path) services defined by the Metro Ethernet Forum (MEF) [6] by VLAN paths whichare established among customer networks by using GMPLS control plane. These Ethernet services are generally usedas a layer-2 VPN by customers. There are two major GMPLS service models which are peer model and overlay model.Both models can be applied to Fig.1. A P2MP VLAN path can be established by setting up Ethernet switches alongthe path route. For establishing a new P2MP VLAN path, two processes are required; collecting topology informationand computing route from sender to receivers (routing), and informing the path state including allocated bandwidth

Customer LAN

Customer LAN Customer LAN

Customer

LAN

Customer

LAN

GMPLS Control-Plane

GMPLS Data-Plane

INGRESS PATH message RSVP-TE Signaling

EGRESS

Point-toPoint PATH with

VLAN ID = 50

Point-to-MultiPoint PATH with VLAN ID = 300

Ethernet frame with

VLAN Tag Headder (ID = 300)

ID = 50

ID = 50

Customer Network Switch

Provider Network Switch

Control Node

Fig. 1. Network Architecture of GMPLS controlled Ethernet

a1041_1.pdf   

OSA / OFC/NFOEC 2010 NThE2.pdf 

 

A B C F

D E

G H

I

(1) (3)

(4)

(2)

(5)

SENDER_TEMPLATE

Sub Grp-Org ID : C

Sub Group ID : 1

S2L_SUB_LSP : F

ERO : F

SENDER_TEMPLATE

Sub Grp-Org ID : G

Sub Group ID : 1

S2L_SUB_LSP : I

ERO : I

SENDER_TEMPLATE

Sub Grp-Org ID : A

Sub Group ID : 1

S2L_SUB_LSP : E

ERO : D - E

to (5)

SENDER_TEMPLATE

Sub Grp-Org ID : C

Sub Grp ID : 2

ERO : G - H

S2L_SUB_LSP : H

S2L_SUB_LSP : I

SERO : H - I

S2L_SUB_LSP : E

S2L_SUB_LSP : F

SERO : C - F

ERO : B - C - D - E

S2L_SUB_LSP : H

SERO : C - G - H

S2L_SUB_LSP : I

SERO : G - I

SENDER_TEMPLATE

Sub Grp-Org ID : A

Sub Group ID : 1

to (2)

to (3)

to (4)

Fig. 2. Example of P2MP Signaling Mechanism

and VLAN ID to all switches for setup the path (signaling). Both routing and signaling run among provider networkedges in the overlay model, among customer edges in the peer model. In this paper, it is assumed that the P2MP pathroute is provided by the router calculation system. Therefore, we can focus on the signaling mechanism.

3. Implementation of P2MP VLAN path signaling3.1 Procedure for P2MP signalingFigure 2 shows an example of signaling scheme for establishing a P2MP path. As described in RFC 4875, the mainRSVP signaling extension to support P2MP path is introducing a Source to Leaf (S2L) sub-LSP which indicates a sub-LSP from a branch Ethernet switch to one of the egress Ethernet switches. Other extensions are P2MP session defini-tion and representation for multiple routes. A newly defined P2MP_LSP_TUNNEL_IPv4(IPv6)_SESSION object in-cludes a P2MP ID. Destination addresses are contained in S2L_SUB_LSP object. P2MP SECONDARY_EXPLICIT_ROUTE object (SERO) represents an explicit route for each destination. One RSVP message contains several pairsof these objects for multiple destinations. We defined detailed procedure for branching messages. A message willbe replicated at the branch node, which is indicated by the first hop of corresponding SERO. When the messageis being replicated, related pairs of S2L_SUB_LSP and SERO are distributed suitably. Only first S2L_SUB_LSPobject is paired by ERO and no SERO follows. Sub-group Originator ID and Sub-Group ID fields extended inP2MP_LSP_TUNNEL_IPv4 (IPv6) SENDER_TEMPLATE object will be set to the node ID and the unique ID in thenode, for each branch. Corresponding P2MP SECONDARY_RECORD_ROUTE object (SRRO) and P2MP LSP_IPv4(IPv6) FILTER_SPEC object is also modified. Other original extensions are shown below. Since an Ethernet path isbidirectional, we extended the procedure for supporting bidirectional path. Also, we defined label allocation and labeldelivery procedure, while an Ethernet path uses a label which is an unique ID in the network such as VLAN ID.

3.2 Newly defined procedure for supporting the overlay model and the peer modelEstablishment of P2MP path contains branch processing which involves not only duplication of data flow in thedata plane, but also signaling to multiple destinations in the control plane; for example, label allocation for multipledownstream interfaces, message replication and combination, and message identification. These processing requiresadvanced implementation for each node but should not always be implemented on all the nodes in the network. Ifthe network employs overlay model as shown in Figure 3-(a), branching will be required on the network edge nodesas well as network intermediate nodes. To support the overlay model, an egress output port indication method isrequired. Egress label control method which adds egress output port information as a label into the last hop of EROis implementable. In addition, to support multiple receivers which are connected to the same egress node as ReceiverC and D in Fig.3-(a), the egress label control method should be extended; this is a further study issue. On the otherhand, if the network employs peer model as shown in Fig.3-(b), the signaling is initiated by a customer network edge

Sender

Receiver A

(a) GMPLS overlay model (b) GMPLS peer model

Receiver B

Receiver D

Receiver C

Sender

Receiver F

Receiver E

Fig. 3. Peer model and Overlay model

a1041_1.pdf   

OSA / OFC/NFOEC 2010 NThE2.pdf 

 

1.1.1.1

3.3.3.3

4.4.4.4

5.5.5.5

6.6.6.6 8.8.8.8

7.7.7.7

9.9.9.9

2.2.2.2

Data plane

Control plane

Sender

Receivers

Ethernet Switch

Control node

Fig. 4. Experimental networkGigabit Ethernet Switches (NETGEAR)

RS-232C

Extended GMPLS programs on Linux PCs

Control-Plane

Data-Plane

GMPLS node

Fig. 5. Experimental equipments

Fig. 6. Captured RSVP-TE message packet

node, not the provider edge node, and terminated by other customer network edge nodes. As a result, the branching isnever required on any customer network edge nodes, but these nodes should support GMPLS P2MP functionalities.

4. P2MP Path Signaling Experiment and ResultsAn experimental P2MP network which emulates GMPLS controlled Ethernet WAN shown in Figure 4 is constructed.This network consists of nine nodes. Two of them are branch nodes. A control plane network and a data plane networkare separately constructed. Therefore, GMPLS messages are exchanged by out-of-fiber/out-of-band technique. For thecontrol plane, an extended RSVP-TE program running on a Linux based PC is implemented. This program is basedon the “GMPLS Engine” developed by NTT-AT Corporation and we added extended program codes for supportingP2MP path establishment. For the data plane, commercially available and VLAN manageable Ethernet switches areused. They are controlled by the GMPLS control plane when a VLAN path is being established or torn down. Theseexperimental equipments are shown in Figure 5. In this trial, the P2MP VLAN path signaling is tested with boththe peer model and the overlay model environments. The examined signaling experiment includes more than twobranching on one node, and branching on the egress node as shown in Fig.4.

The signaling is successfully done, each node exchanges and addresses path messages suitably. On each branchnode, multiple downstream labels are associated to corresponding upstream label, and the Ethernet switch is properlycontrolled. The P2MP VLAN path is established, and connectivity from the sender to the receivers is verified. Thecaptured RSVP-TE message packet is shown in Figure 6. In this figure, the extended objects corresponding to theP2MP signaling are shown.

5. ConclusionThis paper addressed establishment of the P2MP VLAN path on GMPLS controlled Ethernet. The RSVP-TE programis extended and examined in the test network, which supports the peer model and also the overlay model. Theavailability of the automatic P2MP VLAN path provisioning was demonstrated and verified by our implementation.

AcknowledgmentThis work is partially supported by “Lambda Access Project” funded by the National Institute of Information andCommunication Technology (NICT) and Global COE Program “High-Level Global Cooperation for Leading-EdgePlatform on Access Spaces (C12).”

References1. Fouli K. Maier M. “The road to carrier-grade ethernet,” IEEE Communication Magazine, vol.47, no.3, pp.S30-S38, March 2009.2. E. Mannie. (Editor), “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” IETF RFC 3945, Oct. 20043. Don Fedyk, et al, “Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework,”

IETF Internet Draft, draft-ietf-ccamp-gmpls-ethernet-arch-05, Spt. 2009.4. Don Fedyk, et al, “Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE,” IETF Internet Draft, draft-

ietf-ccamp-gmpls-ethernet-pbb-te-02, Feb. 2009.5. R. Aggarwal, et al, “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label

Switched Paths (LSPs),” IETF RFC 4875, May 2007.6. METRO ETHERNET FORUM (MEF) Technical Specification 10.1, “Ethernet Services Attributes Phase 2,”

http://metroethernetforum.org/, June 2008

a1041_1.pdf   

OSA / OFC/NFOEC 2010 NThE2.pdf