Experimental demonstration of ASON-GMPLS signaling ... - IEEE Xplore

Experimental demonstration of ASON-GMPLS signaling interworking in the NOBEL2 Multi-domain Multi-Layer Control Plane Emulator (Invited Paper) R. Mu˜noz, R. Mart´ınez, R. Casellas

R. Morro, C. Cavazzoni

Centre Tecnol`ogic de Telecomunicacions de Catalunya (CTTC), Spain {raul.munoz, ricardo.martinez, ramon.casellas}@cttc.es

Telecom Italia, Italy {roberto.morro,carlo.cavazzoni}@telecomitalia.it

S. Pizzaja, M. Jaeger, H.-M. Foisel

J. Jim´enez, C. Garc´ıa

H. Dentler

Deutsche Telekom, Germany Telef´onica I+D, Spain Alcatel-Lucent, Germany {Sabine.Pizzaja, Monika.Jaeger, Hans-Martin.Foisel}@t-systems.com {fjjc, cgarcia}@tid.es {hdentler}@alcatel-lucent.com

Abstract—Both the OIF and IETF inter-domain interfaces for control plane enabled networks are based on GMPLS protocols. OIF interfaces include ITU-T/ASON specific extensions, resulting in interoperability issues. Moreover, the connection services considered by the OIF are focused on SONET/SDH, OTN (i.e., G.709) and Ethernet, but do not consider lambda services for all-optical transport networks (i.e., without O/E/O conversion) as supported by GMPLS. Previous interoperability experiences are based on implementing an ASON-GMPLS gateway at the edge nodes in order to have the same inter-domain interface between domain edges. Regarding to the LSC switching, it is addressed introducing proprietary extensions to OIF interfaces allowing to request Lambda services. This paper presents a protocol-unaware solution for enabling seamless interworking based on a centralized ASON-GMPLS proxy transparent for domain edges. Experimental demonstration has been performed in the integrated NOBEL2 Pan-European control plane emulator.

I. I NTRODUCTION A key objective of the IST IP NOBEL2 project is the realization of an integrated Pan-European test-bed for the demonstration of innovative experimental activities on advanced control plane functionalities by interconnecting the control plane of seven heterogeneous test-beds [1]. Each involved test-bed supports one or more (data plane) switching capabilities (PSC, TDM, LSC or FSC) coming from different vendors. Moreover, the NOBEL2 network demonstrator is constituted by different ASON and GMPLS administrative domains (control domains), where each domain is agnostic to each other’s signalling and routing protocols. The ITU-T ASON has defined two interfaces specifying the signalling and routing information exchange in each case. The first interface is between the client networks (access network node) and the transport network (core network node) based on an overlay model called User Network Interface or UNI. The second interface is between network domains (core network nodes) based on an overlay/augmented model called External - Network Network Interface or E-NNI. It is worth noting that Internal-NNI I-NNI specification is out of the scope of ASON.

The OIF has defined the OIF UNI 1.0 R2 and OIF UNI 2.0, and the OIF E-NNI 1.0 for ASON architectures. On the other hand, the IETF has defined the GMPLS protocol architecture for peer and augmented networks, and has proposed the Private UNI based on GMPLS-compliant extensions of RSVP-TE for overlay networks called GMPLS-UNI. GMPLS-UNI [IETF RFC4208] and GMPLS [IETF RFC3473] can be independent of one another, which is a requirement of the ASON architectures. OIF and IETF interfaces are both based on GMPLS protocols (i.e., RSVP-TE for signalling and OSPF-TE for routing), allowing the creation of Label Switched Paths (LSPs) in various switching technologies. The OIF interfaces include extensions mandated by ITU-T/ASON architecture. Thus, OIF E-NNI and GMPLS domain are not interoperable. The solution adopted in previous field trials for ASON/GMPLS interworking is to use the same interface (OIF or GMPLS) at both edges between two domains [2] [3] [4] [5]. This approach forces customers/carriers either to use an ASON/GMPLS gateway at border nodes [2] [3] [4] or to implement both stacks of protocols (OIF and GMPLS) [5]. The OIF inter-domain interfaces support SONET/SDH, OTN and Ethernet services. However, Lambda services (used in photonic networks without O/E/O) is only supported by GMPLS. This LSC switching problem is addressed aligning the switching capability at both domain edges to SONET/SDH, requesting TDM services [3] [4]. This solution avoids extending the OIF interfaces with proprietary extensions to request pure Lambda services as in [2]. Therefore, the realization of an integrated large control plane emulator in a Pan-European scenario involves a big challenge that will be tackled in this paper: the interworking between ASON and GMPLS in the heterogeneous multidomain and multi-layer (TDM and LSC) scenario provided by the different available test-beds.

II. ASON-GMPLS I NTERWORKING OF M ULTI -D OMAIN M ULTI - LAYER NETWORKS : P ROBLEM S TATEMENT Signalling is delivered by means of two approaches; single end-to-end session and multi-session connection. GMPLS considers a single end-to-end session used throughout the UNIs, INNIs and E-NNIs involved in the connection. By definition, a session is defined by the endpoints (the source and destination address), and the identifer (Tunnel and LSP ID). Thus, in GMPLS, the source and destination addresses of the session are set to the source and destination client endpoints, that must be defined as reachable addresses. It is worth noting that the connection endpoints are implicit in the session endpoints. In addition, the session identifier must be end-to-end significant. In the second approach (multi-session) standardized by the ITU-T and OIF, a connection crossing multiple domains is separated into two UNI connection segments and several I-NNI and E-NNI connection segments. Each connection segment has its local session identifier, using as source and destination addresses of the session the connection segment end-points. At these interfaces the connection endpoints could not be extracted from the session endpoints. In ASON domains, each UNI connection endpoint is identified by the so-called Transport Network Assigned (TNA) address, that must be globally unique for reachability purposes. A TNA address may adopt one of the following forms: IPv4, IPv6, or NSAP. The TNA addresses are carried within UNI/E-NNI signalling messages to uniquely identify the connection endpoints using the Generalized UNI (G UNI) object. The architecture and routing requirements that an ASON control plane needs to support are standardized in the ITUT Recommendations G.8080 [6], G.7715 [7] and G.7715.1 [8]. Key concepts of these recommendations (e.g., network partitioning, multi-level routing hierarchy, etc.) are devised for scaling the routing protocol in large multi-domain networks. In this context, the OIF approved in 2007 the ENNI routing implementation agreement [9]. This consists in prototype extensions to the GMPLS OSPF-TE protocol [IETF RFC3630, RFC4203] to address the ASON routing architecture. Particularly, these extensions tackle the link identification with full separation between Node IDs, Signalling Controller (SC) IDs, and Routing Controller (RC) IDs, the client reachability exchange and the per layer-specific link capacity advertisement. Analogous to the OIF work, the IETF identified and evaluated, in [IETF RFC4258, RFC4652], the ASON routing requirements for the GMPLS protocols. To do this, new OSPF-TE protocol extensions are proposed in [10]. Besides addressing both the RC/transport node separation and the client reachability advertisement, these extensions also support cross/inter-layer relationships and multi-hierarchical level routing dissemination. Although both OIF and GMPLS efforts aim at conveying the same ASON capabilities, their respective OSPF extensions are significantly different. Seamless E-NNI routing interworking between ASON and GMPLS domains is thus unfeasible mainly due to the non-mature state of the GMPLS OSPF extensions for ASON.

III. R ELATED I NTERWORKING ACTIVITIES Since GMPLS and ASON signalling showed a slight mismatch, previous efforts were made by the R&D and standardization communities to work-around the differences and enable a global interoperability among control planes. The first implementation using ASON-GMPLS gateways was presented by KDDI [3] [4] for SDH on-demand services bridging two SDH ASON domains and one photonic GMPLS domain in the middle. Due to the large similarity of ASON-GMPLS signalling, a GMPLS domain could be included in the OIF Worldwide Interoperability Demonstration in 2005 [5]. Finally, in a Japanese national field trial, a mix of seven ASON and GMPLS domains were interconnected seamlessly by OIF ENNI interfaces [2]. All these implementations have shown that ASON-GMPLS signalling interworking could be implemented with reasonable efforts. Therefore, the OIF started working on a guideline document [11] to feed this R&D knowledge into the standardization work and to detail in a cookbook section the details of the implementation of the ASON-GMPLS gateway. Specifically, this document addresses the interworking of OIF UNI and E-NNI (based on GMPLS RSVP-TE with ASON extensions, per G.7713.2 and OIF IAs) and GMPLS interfaces (based on GMPLS RSVP-TE, per RFC 3473 and RFC 4208). The implementation of the signaling gateway functions in the NOBEL demonstrator described in this paper is compliant with this OIF document. IV. NOBEL2 I NTERWORKING S OLUTION : C ENTRALIZED ASON/GMPLS PROXY The NOBEL2 control plane interconnection (DCN) is composed by 7 test-beds [1], following a star topology throughout a centralized Linux-based star-hub router provided by CTTC (see Fig. 1). The interconnection between the star-hub and each one of the 6 other remote peers is achieved by IPSec tunnels on top of the public Internet (CTTC is connected locally). Additionally, monitoring and accounting tasks are also integrated at the star-hub through a web-based information system (https://nobel-starhub.cttc.es). The monitoring task, implemented using an open-source monitoring tool named Nagios, informs about potential DCN problems (e.g., IPSec tunnel failure). The accounting task that is implemented through the so-called Cacti application leads to acquire star-hub resource data (e.g., CPU load, memory usage), and statistics about the exchanged DCN traffic. For the purpose of ASON-GMPLS interworking, a centralized (NOBEL2) proxy is co-located with the star-hub router at each E-NNI interfacing any pair of domains. The key functionality of the NOBEL2 proxy is to drive RSVP-TE signaling protocol translation whenever a change of domain type occurs (e.g., from ASON to GMPLS). Since the proxy is integrated in the star-hub, all control messages exchanged between peer domains may be captured. That said, any incoming IP packet to the star-hub is checked whether it needs to be processed by the ASON/GMPLS proxy. This verification consists in filtering the packet towards the proxy as long as some rules are satisfied. NOBEL2 ASON/GMPLS proxy is exclusively

AL

CNAF

10.65.0.0/16

10.69.0.0/16

10.65.0.2

10.69.250.1

DT

TI

TID

10.131.0.0/16 10.134.0.0/16 10.67.0.0/16 10.131.17.100 10.134.21.10

10.67.0.69

UPC 10.68.0.0/16

OIF/GMPLS Association Database

SA DB

10.68.0.2 Create and store OIF/GMPLS Session Association

A.B.26.244

C.D.98.2

E.F.67.14

G.H.2.40

I.J.93.157

K.L.32.231

Path

M.N.62.100 Interconnectivity

Monitoring

Yes Yes Path-Error Path-Tear Resv Resv-Conf

RSVP Packet Classify

NOBEL2 star-hub router (Linux-based Router @ CTTC)

OIF-GMPLS Translation

+

No Does Session Exist?

IPSec Tunnels

Internet

+

No

Does Session Exist?

Inter-Domain TE-LINK Database

TDM-LSC Mapping ?

IDTE DB

Yes

No

TDM – LSC Switching Hellos, Acks, Srefresh

+

Accounting

10.64.254.128

Fig. 1.

Fig. 2.

Logical Architecture of ASON/GMPLS Proxy

Physical NOBEL2 DCN control topology.

focused on the RSVP-TE protocol translation. Therefore, the applied rules are: first, check that the IP packet corresponds to a RSVP message; and second, resolve using the IP header source/destination addresses whether a change of domain type exists. If both rules match, then the incoming packet is processed by the proxy (see Section V). Otherwise, the IP packet is directly forwarded trough the outgoing interface. The main benefit of this proxy architecture is that domain border nodes do not need to support dual ASON-GMPLS protocol stack to interwork with peering domains. V. S IGNALLING PROTOCOL I NTERWORKING FOR ASON/GMPLS PROXY The centralized NOBEL2 proxy has two major functions; OIF-GMPLS signalling translation and LSC-TDM switching granularity mapping. The former provides signalling protocol translation between GMPLS and OIF E-NNI 1.0 when it detects a Path/Resv message crossing different inter-domain interfaces between two test-beds. The latter provides switching mapping between LSC LSP and TDM LSP. It is worth noting that the proposed TDM-LSC switching mapping assigns a whole wavelength for each TDM request. Thus, for an optimum configuration, it forces TDM domains to request the maximum available bandwidth for each inter-domain TE link connecting two domains, since no TDM grooming can be performed. Otherwise, multi-layer signalling should be required. A. ASON-GMPLS proxy Architecture The architecture of the ASON-GMPLS proxy is the one shown in Fig. 2. Two key elements of the proxy are the OIF/GMPLS association database (SA-DB) and the Interdomain TE-link Database (IDTE-DB). The former is responsible for univocally associating the received OIF or GMPLS session with its equivalent GMPLS or OIF session. Thus, for each received connection request (i.e., RSVP-TE Path message) with a new GMPLS or OIF session (i.e., not previously stored in the SA-DB), the proxy generates the equivalent OIF or GMPLS session and stores them in the SA-DB along with the inter-domain TE link where the connection is being requested

(inferred from the received RSVP-HOP object). This threetuple is removed when the connection is torn down through an RSVP-TE Path-Error or Path-Tear. The conversion rules between OIF and GMPLS sessions are based on the pseudo session interworking mechanism proposed in [2]. Specifically, the generation of the OIF session from the received GMPLS session is as follows: Generated E-NNI IPv4 SESSION Object – IPv4 address: Received IP Header ⇒ Destination address. – Tunnel ID: Received LSP TUNNEL IPv4 SESSION object ⇒ Tunnel Id. – Extended IPv4 address: Received IP Header ⇒ Source address. • Generated SENDER TEMPLATE Object – IPv4 address: Received IP Header ⇒ Source address. – LSP ID: Received SENDER TEMPLATE ⇒ LSP ID On the other hand, the generation of the GMPLS session from the received OIF session is based on the following rules: •

Generated LSP TUNNEL IPv4 SESSION object – IPv4 Tunnel End point address: Received Generalized UNI object ⇒ Destination IPv4 TNA address. – Tunnel ID: Received E-NNI IPv4 SESSION object ⇒ Tunnel Id – Extended Tunnel ID: Received Generalized UNI object ⇒ Source IPv4 TNA address. • Generated SENDER TEMPLATE object – IPv4 address: Received Generalized UNI object ⇒ Source IPv4 TNA address. – LSP ID: Received SENDER TEMPLATE ⇒ LSP ID Finally, the IDTE-DB repository collects all the information of the inter-domain TE links connecting two domains with different switching capabilities. For each inter-domain TE link, the stored attributes of the two edge domains are the Node and Link Identifier, Switching Type, Encoding Type, bandwidth, •

and wavelength. Label Identifier is required just for LSC domains.

•

B. OIF-GMPLS Signaling translation When the RSVP-TE packets arrive to the OIF-GMPLS Signaling translation module, the first action is to look up the associated OIF or GMPLS session for the incoming OIF/GMPLS session in the SA-DB, in order to obtain the required information for the signaling translation. As stated above, the two main components of the signaling translation are the mapping of the session endpoints and the connection endpoints between OIF and GMPLS. The rules for the mapping of the session and connection endpoints are as follows: • Session Endpoints (Path, Resv, Path-Error, Path-Tear, Resv-Conf messages. No action for other messages) – From GMPLS to OIF: Replace the LSP TUNNEL IPv4 SESSION and SENDER TEMPLATE/ FILTER SPEC objects by the E-NNI IPv4 SESSION and the SENDER TEMPLATE objects stored in the SA-DB. – From OIF to GMPLS: Replace the E-NNI IPv4 SESSION and the SENDER TEMPLATE / FILTER SPEC objects by the LSP TUNNEL IPv4 SESSION and the SENDER TEMPLATE objects stored in the SA-DB. • Connections Endpoints (Path message. No action for other messages): – From OIF to GMPLS: No action is required. Connection endpoints are implicit in the GMPLS session. – From GMPLS to OIF: Generate the GENERALIZED UNI object: ∗ Destination IPv4 TNA address: Received LSP TUNNEL IPv4 SESSION object ⇒ IPv4 Tunnel End point address. ∗ Source IPv4 TNA address: Received SENDER TEMPLATE object ⇒ IPv4 address. C. LSC-TDM Switching Mapping The first action of the LSC-TDM Switching Mapping module is to look up the associated Inter-Domain TE link for the incoming OIF/GMPLS session in the SA-DB. Then, the proxy performs a second look up of all the attributes for this TE link in the IDTE-DB required for the Switching Mapping. It is worth noting that a null response from this query implies that no LSC-TDM mapping is required. After that, the proxy has enough information to proceed with the mapping of the Generalized Label Request, Traffic Parameters, and Generalized Labels as follows: • Generalized Label Request (Path, Resv messages. No action other messages): – Modify the GENERALIZED LABEL REQUEST object, using the Switching and Encoding type stored in the IDTE DB.

•

Traffic parameters (Path, Resv, Path-Error, Path-Tear, Resv-Conf. No action for other messages): – From TDM to LSC: Generate the lambdarelated SENDER TSPEC / FLOWSPEC object from the Bandwidth Information stored in the IDTE DB. The received SONET/SDH SENDER TSPEC / FLOWSPEC objects are set to transparent objects (Class-Num 208 and 210 respectively). Class-Nums higher than 192 force the node to ignore the object and forward it without changes. – From LSC to TDM: Remove the received lambda-related SENDER TSPEC / FLOWSPEC Object and restore the received TRANSPARENT SONET/SDH SENDER TSPEC / FLOWSPEC Object with their standard class-num. Generalized Label(Path, Resv, Path-Error, Path-Tear, Resv-Conf messages. No action for other messages): – From TDM to LSC: The received SONET/SDH Labels in the GENERALIZED / UPSTREAM LABEL objects are replaced by wavelength labels stored in the IDTE DB. The received SDH-related GENERALIZED / UPSTREAM LABEL object are set to transparent objects (Class-Num 211 and 209, respectively). – From LSC to TDM: Remove the received lambdarelated GENERALIZED/UPSTREAM LABEL objects and restore the received SDHrelated TRANSPARENT GENERALIZED/UPSTREAM LABEL objects with their standard class-num.

VI. NOBEL2 APPROACH FOR M ULTI - DOMAIN ROUTING EXCHANGE

A prerequisite for the ASON OSPF routing is that each control domain has at least one RC for coordinating/disseminating routing information between peer RCs [7]. For ASON domains, the used RC is aligned with the already demonstrated OIF E-NNI OSPF implementation [9]. However, within the IETF framework, ASON extensions to GMPLS OSPF-TE protocol are not yet mature. Thus, the adopted NOBEL2 approach for the multi-domain routing interworking consists in exclusively relying on the OIF ASON routing. Thereby, the routing information is exchanged between ASON and GMPLS domains by allocating in each of these domains an OIF E-NNI OSPF 1.0 RC, as shown in Fig. 3. According to this routing model, RCs forming routing adjacencies are most likely not topologically adjacent (i.e., one IP-hop away) within the control plane (DCN). Therefore, this requires a different usage of the OSPF protocol to create the adjacency. The OIF E-NNI adopts a variation of the OSPF point-tomultipoint method in which the RC adjacencies are manually configured, and the OSPF Hello protocol is not used for discovery purposes but for maintaining the adjacency only. As in OSPFv2, as soon as the adjacency is created, the two RCs can exchange their databases. TE link attributes are

OIF E-NNI OSPF 1.0 EMULATED CTTC RC OIF E-NNI OSPF 1.0

TID– CTTC Routing Adjacency

TID RC

10.134.21.102

10.67.1.1

ERC

ALU

UNI

ASON NETWORK 10.67.1.1

OIF E-NNI 1.0 (TDM)

ASON ASON TDM TDM OIF UNI 1.0 R2 (TDM)

OIF E-NNI OSPF 1.0 DT RC

ERC

SDH client

ALU E-NNI TID-CTTC

TNAs 67.1.1.1 67.1.1.2

CTTC – DT Routing Adjacency

10.134.21.105

0xc6ac8d

GMPLS NETWORK

GMPLS 10.64.50.2 10.64.50.1 GMPLS (LSC) (LSC) GMPLS GMPLS LSC 0x7d0 0xc6ac8d LSC

ASON/GMPLS Proxy

Transport network node

E-NNI DT-CTTC

OIF E-NNI 1.0 (TDM)

ASON NETWORK

0xc74ac1

D Cologne

Hamburg Hannover Berlin

Dortmund

Frankfurt Mannheim

ALU

ALU

Bremen

Essen

10.131.2.2 ASON/GMPLS Proxy

No rde n

Leipzig

TNAs 131.2.1.1 UNI 131.2.1.2

Nuremberg

Karlsruhe Stuttgart Ulm Munich

Fig. 3.

NOBEL2 Interworking Scenario Topology

exchanged according to the GMPLS OSPF-TE specifications but containing extensions with new TLVs needed to fulfill the ASON requirements as described in Section II. VII. E XPERIMENTAL D EMONSTRATION A. Interworking Scenario Topology The topology used for the demonstration and validation is a multi-Domain multi-Layer network composed of 3 domains (cfr. Fig. 3): Two ASON domains (TID and DT, identified by prefixes 10.67.0.0/16 and 10.131.0.0/16 respectively), connected either directly or via a GMPLS LSC domain (CTTC, prefix 10.64.0.0/16). 1) ASON Domains: The TID ASON domain consists of commercial GMPLS NG-SDH switches (Alcatel-Lucent 1678 MCC), which provide distributed control plane capabilities. The system design is based on a 6-slot architecture, each slot delivering 40Gbps bandwidth capacity, and is currently equipped with STM-16 and STM-64 interfaces. The I-NNI control plane is based on standard GMPLS routing and signalling protocols, enhanced with vendor specific features. Standard OIF E-NNI signalling is also available, allowing for multi-domain connection provisioning. At DT there are two ASON domains, one consisting of an Alcatel-Lucent 1678 MCC node, the other is an emulated simplified German transport network domain of 17 emulated nodes [12] with real, fully-functional protocol stacks and configurable signalling and routing parameters. All nodes are interconnected via OIF E-NNI control plane interfaces, a couple of them terminating additionally OIF UNI links to SDH clients. This 17-node domain could be linked via OIF UNI and E-NNI links to other emulated or real domains. With this configuration SDH-SPC and SDH-SC (Soft Permanent and Switched Connections) could be initiated or handled, e.g. by the node in Berlin or the attached UNI-client instance. 2) GMPLS Domain: The GMPLS domain at CTTC is an intelligent wavelength routed network. The transport plane consists of two colorless ROADMs connected by a bidirectional DWDM link, controlled by two Optical Connection

Controllers running IETF GMPLS RSVP-TE with Refresh Reduction Capabilities, and OSPF-TE. B. Traffic request The connection requests are initiated and terminated by OIF UNI clients using STM-16 interfaces in all the ASON SDH domains (i.e., DT and TID). To this end, SDH LSPs are routed through the intermediate GMPLS photonic domain (CTTC) using the E-NNI interfaces connecting both ASON domains. This, in turn, leads to provide Bandwidth on Demand (BoD) services over a multi-domain and multi-layer Pan-European network. For the sake of completeness, ondemand SDH-SPC and SDH-SC request signals with STS-3c SPE / VC-4 bandwidth granularity (150 Mbps) using virtual concatenation within STM-16 signals. Therefore, the encoding type and switching granularity of these connection demands are SONET/SDH and TDM, respectively. C. Validation and Results Let us illustrate the processing of RSVP-TE messages during the successful establishment of an end to end multilayer multi-domain LSP, from the DT domain to the TID domain, i.e. between TNAs 131.2.1.1 and 67.1.1.1. The first trace (Fig. 4(a)) shows the ASON E-NNI Path message at the DT-CTTC E-NNI interface. The IPv4 E-NNI session is defined between nodes 10.131.2.2 (DT node) and 10.64.50.1 (CTTC node). It is a request for a VC-4 SDH LSP. Fig. 4(b) shows the same Path message once translated by the proxy. Note the piggybacked transparent objects, and a single session appears (as required by the IETF GMPLS documents) with the TNA addresses. Without a mechanism to translate generic TNA addresses to IPv4 IETF GMPLS session address and extended tunnel identifier, TNAs need to be reachable IPv4 addresses. Upon reception of the Path message, the destination node (TNA) sends back a RESV message, translated similarly to the Path message (see Fig. 4(c) and (d)). Once the head-end node receives the Resv message, it sends a ResvConf message to the tail-end, also translated following the same rules. At this

(a) ASON Domain - Path

(b) GMPLS Domain - Path

(c) GMPLS Domain - Resv

(d) ASON Domain - Resv

Fig. 4.

RSVP-TE Path message at both the ASON and GMPLS domains, CTTC-DT E-NNI interface

point, the LSP has been established between the two ASON domains. The head end and tail end of the LSP see a VC4 LSP, which is being mapped to a wavelength. The GMPLS domain sees a single end to end (w.r.t. its domain) LSC LSP. It is important to note that, for the purposes of this experiment, a full wavelength is allocated to the VC-4, a drawback of this approach. Indeed, a single SDH LSP is mapped to a LSC LSP in a 1:1 setting. In order to validate the release of the LSP, the head end sends a Path with Reflection Deleting flags and the egress node responds with a Path Error with Error Code and Value (0,0) confirming the deletion of the connection (captures not shown due to space constraints). VIII. C ONCLUSIONS We have summarized the work carried out in the Nobel 2 project, where an interworking approach has been presented, and validated. The solution requires accounting for identified gaps or divergences in the current status of normalization, considering that current OIF E-NNI documents do not include the request for plain lambda services in transparent, optical networks such as GMPLS LSC, but support OTN formats. The proposed proxy implementation is based on protocol and object translation rules and ad-hoc solutions to the switching layer mismatch. This approach should be considered an interim one, to address the aforementioned shortcomings and testbeds differences. The actual interworking issue should be addressed by extending existing protocols and covering new use cases where appropriate, driven by requirements of network operators not met by existing standards, addressing a formal notification / request to the corresponding standardization bodies and fora. In this sense, contacts among members of OIF, ITU-T and IETF, which also participate in the NOBEL2 project have been established.

ACKNOWLEDGEMENT

This work is partially supported by the IST IP NOBEL2 project, (FP6-027305) R EFERENCES [1] R. Munoz et al, “Experimental interconnection and interworking of the multi-domain (ASON-GMPLS) and multi-layer (TDM-LSC) Nobel2 Test-beds,” in Proc. 33rd European Conference on Optical Communications (ECOC), Sept. 2007. [2] S. Okamoto, T.Otani, Y.Sone, W.Imajuku, K.Ogaki, M.Miyazawa, I.Nishioka, K. Miyazaki, A.Nagata, S.Seno, D.Ishii, S.Okamoto, N.Arai, and H.Otsuki, “Field trial of signaling interworking of multi-carrier ason/gmpls network domains,” in Proc. OSA Optical Fiber Conference (OFC), March 2006. [3] M. Hayashi et al., “Peer/overlay hybrid optical network using protocol gateways of gmpls and oif-uni/nni,” in Proc. OSA Optical Fiber Conference (OFC), 2005. [4] T. Otani, “Ason - gmpls interworking - practical implementation of interoperable solutions,” in Proc. ECOC Workshop on Interoperability topics in Next Generation Transport Networks, 2005. [5] J. Jones et al., “Alcatel presentation at the oif worldwide interoperability demonstration supercomm 2005,” in www.oiforum.com/public/downloads/Alcatel-05.pdf, 2005. [6] G.8080/Y.1304, “Architecture for the Automatically Switched Optical Network (ASON),” ITU-T Recommendation, November 2001. [7] G.7715/Y.1706, “Architecure and Requirements for Routing in the Automatically Switched Optical Network,” ITU-T Recommendation, June 2002. [8] G.7715.1/Y.1706.1, “ASON Routing Architecture and Requirements for Link State Protocols,” ITU-T Recommendation, November 2003. [9] OIF, “OIF-ENNI-OSPF-01.0 - External Network-Network Interface (ENNI) OSPF-Based Routing - 1.0 (Intra-Carrier) Implementation Agreement,” Optical Internetworking Forum, January 2007. [10] D. Papadimitriou, “OSPFv2 Routing Protocols Extensions for ASON routing,” draft-ietf-ccamp-gmpls-ason-routing-ospf, March 2007. [11] oif2006.028, “OIF Guideline Document: Signaling Protocol Interworking of ASON/GMPLS network domains,” Optical Internetworking Forum, November 2007. [12] R. Huelsermann et al., “A set of typical transport network scenarios for network modelling,” in ITG Fachbericht 182, 2004, pp. 65–71.