Orange

Rennes 35000 France mohamed.boucadair@orange.com

Deutsche Telekom AG

CTO-ATI, Landgrabenweg 151 Bonn NRW 53227 Germany ian.farrer@telekom.de

Cisco Systems, Inc.

7025 Kit Creek Rd. RTP NC 27709 United States of America Rajiva@cisco.com

Softwire Working Group softwire Augment tunnel tunnel management tunnel provisioning tunnel activation tunnel automation This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website. Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly. Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• .  Introduction
• .  IANA Tunnel Type YANG Module
• .  Security Considerations
• .  IANA Considerations
  • .  YANG Module
  • .  Updates to the IANA tunnelType Table
• .  References
  • .  Normative References
  • .  Informative References
• .  Example Usage
• Acknowledgements
• Authors' Addresses

Introduction This document specifies the initial version of the iana-tunnel-type YANG module containing a collection of IANA-maintained YANG identities identifying tunnel interface types. The module reflects IANA's tunnelType registry under the SMI Numbers registry . The latest revision of this module can be obtained from the IANA website. Tunnel-specific extensions may be added to the Interface module as a function of the tunnel type. An example of this is provided in . It is not the intention of this document to define tunnel-specific extensions for every tunnel encapsulation technology; those are discussed in dedicated documents such as . Likewise, it is out of the scope of this document to update the existing IANA tunnelType registry with a comprehensive list of tunnel technologies. Guidelines and registration procedures for interface types and sub-types are discussed in . This document uses the common YANG types defined in and adopts the Network Management Datastore Architecture (NMDA ). The terminology for describing YANG modules is defined in . The meanings of the symbols used in the tree diagram are defined in .

IANA Tunnel Type YANG Module The iana-tunnel-type module imports the 'iana-if-type' module defined in . The initial version of the module includes tunnel types defined in , , , and . module iana-tunnel-type { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-tunnel-type"; prefix iana-tunnel-type; import iana-if-type { prefix ift; reference "RFC 7224: IANA Interface Type YANG Module"; } organization "IANA"; contact "Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 <mailto:iana@iana.org>"; description "This module contains a collection of YANG identities defined by IANA and used as interface types for tunnel interfaces. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8675; see the RFC itself for full legal notices."; revision 2019-11-16 { description "Initial revision."; reference "RFC 8675: A YANG Data Model for Tunnel Interface Types"; } identity other { base ift:tunnel; description "None of the following values."; reference "RFC 4087: IP Tunnel MIB"; } identity direct { base ift:tunnel; description "No intermediate header."; reference "RFC 2003: IP Encapsulation within IP RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers"; } identity gre { base ift:tunnel; description "GRE encapsulation."; reference "RFC 1701: Generic Routing Encapsulation (GRE) RFC 1702: Generic Routing Encapsulation over IPv4 networks RFC 7676: IPv6 Support for Generic Routing Encapsulation (GRE)"; } identity minimal { base ift:tunnel; description "Minimal encapsulation."; reference "RFC 2004: Minimal Encapsulation within IP"; } identity l2tp { base ift:tunnel; description "L2TP encapsulation."; reference "RFC 2661: Layer Two Tunneling Protocol 'L2TP'"; } identity pptp { base ift:tunnel; description "PPTP encapsulation."; reference "RFC 2637: Point-to-Point Tunneling Protocol (PPTP)"; } identity l2f { base ift:tunnel; description "L2F encapsulation."; reference "RFC 2341: Cisco Layer Two Forwarding (Protocol) 'L2F'"; } identity udp { base ift:tunnel; description "UDP encapsulation."; reference "RFC 1234: Tunneling IPX Traffic through IP Networks, RFC 8085: UDP Usage Guidelines, Section 3.1.11"; } identity atmp { base ift:tunnel; description "ATMP encapsulation."; reference "RFC 2107: Ascend Tunnel Management Protocol - ATMP"; } identity msdp { base ift:tunnel; description "MSDP encapsulation."; reference "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; } identity sixtofour { base ift:tunnel; description "6to4 encapsulation."; reference "RFC 3056: Connection of IPv6 Domains via IPv4 Clouds"; } identity sixoverfour { base ift:tunnel; description "6over4 encapsulation."; reference "RFC 2529: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"; } identity isatap { base ift:tunnel; description "ISATAP encapsulation."; reference "RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)"; } identity teredo { base ift:tunnel; description "Teredo encapsulation."; reference "RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)"; } identity iphttps { base ift:tunnel; description "IP over HTTPS (IP-HTTPS) Tunneling Protocol."; reference "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling Protocol Specification, https://msdn.microsoft.com/en-us/library/dd358571.aspx"; } identity softwiremesh { base ift:tunnel; description "softwire mesh tunnel."; reference "RFC 5565: Softwire Mesh Framework"; } identity dslite { base ift:tunnel; description "DS-Lite tunnel."; reference "RFC 6333: Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"; } identity aplusp { base ift:tunnel; description "A+P encapsulation."; reference "RFC 6346: The Address plus Port (A+P) Approach to the IPv4 Address Shortage"; } }

Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The module defined in this document defines YANG identities for the iana-tunnel-types registry. These identities are intended to be referenced by other YANG modules, and by themselves do not expose any nodes which are writable, contain read-only state, or RPCs. As such, there are no additional security issues to be considered relating to the module defined in this document.

IANA Considerations

YANG Module IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" :

URI:

urn:ietf:params:xml:ns:yang:iana-tunnel-type

Registrant Contact:

IANA

XML:

N/A; the requested URI is an XML namespace.

IANA registered the following YANG module in the "YANG Module Names" subregistry within the "YANG Parameters" registry.

Name:

iana-tunnel-type

Namespace:

urn:ietf:params:xml:ns:yang:iana-tunnel-type

Prefix:

iana-tunnel-type

Reference:

RFC 8675

This document defines the initial version of the IANA-maintained iana-tunnel-type YANG module. IANA has added this note to the registry:

• Tunnel type values must not be directly added to the iana-tunnel-type YANG module. They must instead be added to the "tunnelType" subregistry (under the "ifType definitions" registry) at [IANA registry smi-numbers].

When a tunnel type is added to the "tunnelType" subregistry, a new "identity" statement must be added to the iana-tunnel-type YANG module. The name of the "identity" is the lower-case of the corresponding enumeration in the IANAifType-MIB (i.e., IANAtunnelType). The "identity" statement should have the following sub-statements defined:

"base":

Contains 'ift:tunnel'.

"description":

Replicates the description from the registry.

"reference":

Replicates the reference from the registry and adds the title of the document.

Unassigned or reserved values are not present in the module. When the iana-tunnel-type YANG module is updated, a new "revision" statement must be added in front of the existing revision statements. IANA has added the following note to "tunnelType" subregistry:

• When this registry is modified, the YANG module iana-tunnel-type must be updated as defined in RFC 8675.

Updates to the IANA tunnelType Table IANA has updated the following entries in the tunnelType registry under the SMI Numbers registry . OLD:

Decimal	Name	Description	References
2	direct	no intermediate header
3	gre	GRE encapsulation
4	minimal	Minimal encapsulation
5	l2tp	L2TP encapsulation
6	pptp	PPTP encapsulation
7	l2f	L2F encapsulation
8	udp	UDP encapsulation
9	atmp	ATMP encapsulation
10	msdp	MSDP encapsulation
11	sixToFour	6to4 encapsulation
12	sixOverFour	6over4 encapsulation
13	isatap	ISATAP encapsulation
14	teredo	Teredo encapsulation
16	softwireMesh	softwire mesh tunnel
17	dsLite	DS-Lite tunnel

NEW:

Decimal	Name	Description	References
2	direct	no intermediate header
3	gre	GRE encapsulation
4	minimal	Minimal encapsulation
5	l2tp	L2TP encapsulation
6	pptp	PPTP encapsulation
7	l2f	L2F encapsulation
8	udp	UDP encapsulation
9	atmp	ATMP encapsulation
10	msdp	MSDP encapsulation
11	sixToFour	6to4 encapsulation
12	sixOverFour	6over4 encapsulation
13	isatap	ISATAP encapsulation
14	teredo	Teredo encapsulation
16	softwireMesh	softwire mesh tunnel
17	dsLite	DS-Lite tunnel

References Normative References This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document defines the initial version of the iana-if-type YANG module. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. IANA Informative References This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANA Considerations sections and YANG modules, and so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC 2863, and provides updated guidance for these registries. Work in Progress This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK] This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK] This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind. This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK] This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community. This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK] This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK] The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations. This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK] This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. [STANDARDS-TRACK] We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK] The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community. The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK] This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK] We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community. Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing a softwire mesh. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite). The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223.

Example Usage The following example illustrates how the Interface YANG module can be augmented with tunnel-specific parameters. In this example, the module is augmented with a 'remote-endpoint' for the tunnel. A tree structure is provided below: module: example-iftunnel-extension augment /if:interfaces/if:interface: +--rw remote-endpoint? inet:ipv6-address The 'example-iftunnel-extension' module imports the modules defined in and in addition to the "iana-tunnel-type" module defined in this document. module example-iftunnel-extension { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:example-iftunnel-extension"; prefix example; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types, Section 4"; } import ietf-interfaces { prefix if; reference "RFC 8343: A YANG Data Model for Interface Management"; } import iana-tunnel-type { prefix iana-tunnel-type; reference "RFC 8675: A Tunnel Extension to the Interface Management YANG Module"; } organization "IETF Softwire Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/softwire/> WG List: <mailto:softwire@ietf.org> Author: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com>"; description "This is an example YANG module to extend the Interface YANG module with tunnel-specific parameters. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8675; see the RFC itself for full legal notices."; revision 2019-10-21 { description "Initial revision."; reference "RFC 8675: Tunnel Interface Types YANG Module"; } augment "/if:interfaces/if:interface" { when "derived-from(if:type, 'iana-tunnel-type:gre')"; description "Augments Interface module with specific tunnel parameters."; leaf remote-endpoint { type inet:ipv6-address; description "IPv6 address of the remote GRE endpoint."; } } }

Acknowledgements Special thanks to Tom Petch and Martin Bjorklund for the detailed review and suggestions. Thanks to Andy Bierman for the Yangdoctors review. Thanks to Dale Worley, David Black, and Yaron Sheffer for the review.

Authors' Addresses Orange

Rennes 35000 France mohamed.boucadair@orange.com

Deutsche Telekom AG

CTO-ATI, Landgrabenweg 151 Bonn NRW 53227 Germany ian.farrer@telekom.de

Cisco Systems, Inc.

7025 Kit Creek Rd. RTP NC 27709 United States of America Rajiva@cisco.com