Submitted to NAT Working Group C. Zaccone Y. T'Joens, B. Sales INTERNET DRAFT Alcatel March 3, 2000 Expires September 3, 2000 Mechanisms for end-2end native transport Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes some mechanisms to enable an IP network to transport both the IP traffic of the local realm and the IP traffics of external realms in the native (non-tunneled) way [TRANSP-FRAM]. The methods, described in this document, provide to the routers of the operated network the necessary information enabling the delivery of IP traffics originated from the foreign realms the operator offer connectivity to. This information is derived by the currently available routing information routers have and is moreover provided to them by the mean of a local delivery mechanism. Zaccone, et al. Expires September 3, 2000 [Page 1] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 Table of Contents 1. Introduction 2. Terminology 3. OSPF Minimized Router Deamon 4. Using a multicast protocol 5. Using RSVP 6. Conclusion 7. Security Considerations 8. Acknowledgements 9. References 1. Introduction In an environment where an IP network operator offer connectivity to other IP realms that the local one, different schemes enabling this objective are possible. Those schemes, described in [TRANSP-FRAM], differ from the type of access provided to the customer: physical or logical links towards foreign realms. In the former one, the operator provide to the customer a physical connection for the required foreign realms whereas in the latter one the operator emulate those links across its network by the use of a transport technology. The different transport technologies, also described in [TRANSP-FRAM], are the tunneled and non tunneled approaches. Currently, the transport of datagrams, pertaining to other realms that the local one, is realised by the use of a tunneling technology. However, tunneling technology is not without any inconveniences. In this document, we will describe and discus several possible mechanisms enabling the operator to deploy the non tunneled approach. In extenso, those mechanisms will enable the operator's routers to obtain the necessary routing information to delivers datagram issued from foreign realms to hosts logically connected to those realms. 2. Terminology In the context of this document, the authors assume readers are familiar with the terminology as described in [TRANSP-FRAM]. 3. OSPF Minimized router deamon (OMRD) Most of the time, the Open Short Path First ([OSPF],[OSPF_V6]) protocol is the one running in autonomous domain. In OSPF, a router in the domain constantly informs its neighbour router(s) of its current 'UP' ("OK! I work") status by means of keep alive message called 'Hello message'. Another feature of the protocol is that it Zaccone, et al. Expires September 3, 2000 [Page 2] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 allows for autoconfiguration of peer routers in the domain (a router could dynamically, but with authentication, become part of the routing domain and advertise to its neighbour the status of its links). This autoconfiguration capability can be deployed to indicate the position of the host with a foreign IP address. In the OMRD mechanism, each host is a kind of 'sleeping router'. The term 'sleeping router' denotes that as soon as the host wishes to have outbound access towards a foreign realm, it will participate to the domain's routing. The objective of that participation is to realise the update of the internal routing in order that datagrams having the foreign IP address of that host as destination address are routed to a router which has direct connectivity with the host. The special case here being that this router is the host itself. Using the previously mentioned dynamicity of OSPF, it is possible to advertise in the network the host as a new router. The minimized aspect of the router is due to the fact that only a restricted number of OSPF routing functionality are present. Indeed, it do not have to botter about link advertisement issued from other routers. Therefore, it do not have to manage the OSPF links database and associated route calculation. Finally, it does not participate in the 'designated router' election on the LAN segment. In short, this router has only to advertise itself to the neighbour, advertise reachability to a single IP address and flush this information as soon as it is obsolete. The advantage of this mechanism is that the core routers do not need to be modified. As described before, the OSPF flooding procedure started by the host routing daemon has as objective to inform the entire network of the reachability to the (newly assigned) IP address. However, the propagation of the information and the recomputing of the OSPF algorithm takes time and could let a host which is configured for Internet connectivity to be considered by a router as unreachable just because this one is not synchronized yet. This converging time puts temporary the network in an incomplete state where the way to a destination is not known at the moment. Note that the synchronization time of the network is function of its size, which therefore may impact the deployement of such mechanism. 4. Using a multicast protocol. In a multicast domain, when a host subscribes to a certain multicast group, a multicast tree for that multicast group is first created (for the first subscriber) and then extented (for new subscribers). The multicast tree describes the path the datagrams have to follow Zaccone, et al. Expires September 3, 2000 [Page 3] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 from the sender of the multicast traffic towards the receiver. +---------- | .---. | | | Sender | ----- | / \ | -------** | | * DESTINATION IS A | + * MULTICAST IP ADDRESS Multicast | +--+ \/ ------| | | domain | +--+ | /\ | +--+ +--+ | | | | | | +--+ +--+ | / \ | +--+ .---. | | | | | Receiver | +--+ / \ | | \ ------- | .---. \ |Receiver| | \ | ----- .---. | / \ | |Reiceiver | ------- ----- | / \ | ------- +---------- Multicast tree example In multicast capable domains, the configuration of the tree is subject to the specifics of the multicast protocol. When that multicast protocol would be able to setup trees for a unicast IP addres, it could be used to set up a reverse path to the host with the foreign IP address. The setup of a reverse path could be seen as the creation of a native multicast tree by the first subscriber. The mechanism to create reverse paths will be the following. Assuming that the host has determined that it needs foreign connectivity, and that it gets the configuration information (the IP stack configuration parameter), it will send a join message to the local multicast capable router. The router runs a multicast protocol (e.g., PIM) and so allows to set up a reverse path to other multicast capable routers, including the border routers. Zaccone, et al. Expires September 3, 2000 [Page 4] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 When the host determines to release its foreign IP address, a leave message for the corresponding IP address will be send in order to remove the unicast tree and therefore the reverse path which transports the traffic (to that foreign IP address) in the direction of that host. +---------- | .---. | | | Sender Foreign realm ---| ----- | / \ | -------** +---------- | * DESTINATION IS AN +---------- + * FOREIGN IP ADDRESS | +--+ \/ | Border | | | router +--+ | / | +--+ Local realm ---| | | | +--+ | | | .---. |Host X | | | ----- | / \ | ------- +---------- Unicast tree example The advantage of that mechanism is that it inherits the tree setup and maintenance of multicast protocols. However, it requires that both the host and the network are multicast capable and that the multicast protocol supports the use of non class D IP addresses. 5. Using RSVP Another way to allow the set up of a reverse path is the use of (an extended) RSVP. That is to say, RSVP will be used to update only routers on the path (generally the shortest one) between a host which gets a foreign IP address and router(s) connected to the foreign realm which owns that foreign IP address. In order to create the reverse path, every time a host is configured with a foreign IP address, the RSVP protocol will be used between the host and edge routers which are connected to the foreign realm that supplied the IP address. For those communications, hosts will use the Zaccone, et al. Expires September 3, 2000 [Page 5] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 local IP addresses they are assigned. To be able to contact edge routers, hosts need to obtain their IP addresses. To that aim, hosts may either obtain (e.g. at IP stack configuration time) a list of edge routes unicast IP addresses or either a list of foreign realm multicast IP addresse (if we consider that the network is multicast capable, one may associate a multicast group address with each different foreign realms. The edge routers subscribe to the foreign realm group address to which they are connected, so that they may be also reachable via the foreign realm multicast group address they have a subscription to) The list of edge routers unicast IP addresses will be used to contact those edge routers one by one whereas the foreign realm multicast IP address will be used to contact all those edge routers by a single message addressed to the group address associated with the foreign realm from which the allocated IP address is issued. In order to setup reverse path(s), a host will send a RSVP PATH message with a to be defined new object. That new object will contain the foreign IP address the host has been assigned. As the network is already able to route the edge routers unicast (local) IP addresses (or the foreign realm multicast IP address), the RSVP message will reach those routers using the current paths between them and the host. Each time the RSVP message will cross a router (hop by hop), it will be interpreted by the router and the required routing table entry (IP address -> Forwarding Interface) will be added to the current routing database. This routing information will depend on the direction on wich the RSVP message is interpreted. In the direction of the edge routers, the routing information to add is to forward datagrams with the IP address contained in the object towards the interface where the RSVP PATH message arrived. Whereas in the direction of the host, the routing information to add is to forward datagrams with the IP address contained in the object towards the interface where the RSVP RESERVE message has to be forwarded to. The choice of one or the other is open. When RSVP is used for QoS, actions (resources reservation) related to RSVP messages are applied according to the second choice with the RESERVE message. This choice is inherent to QoS (for outgoing traffic) resource reservation. Here, updating the routing table does not have the same impact as reserving resources without using them. The next figure shows an example of the mechanism. As soon as the host has been configured for connectivity to foreign realm Realm2 (let us say with those information: IP_Y_Realm2 as IP address and R3 as edge routers unicast list), it will send a PATH message towards Zaccone, et al. Expires September 3, 2000 [Page 6] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 router R3 which is connected to the Realm2. Let us consider the case where RSVP messages are interpreted when going towards router R3. When the PATH message arrives at R1, it analyses the associated object, discovers the public IP address and creates the entry (IP_Y_Realm2 -> Interface I.1) in its routing database. The PATH message will flow hop by hop until it reachs router R3, with the same use of the object. When the entire path is realised, a reverse path is established. .---. Host X | | R1 | R2 | ----- +--+ I.2| +--+ | R3 : / \ | |+---/ | |+---/ Border router ------- +--+ +--+ +--+ +-------+ +-------+ +--------+| |+--Realm2 I.1 I.3 +--+ ...............................> | RSVP 'setup reverse path' Message ---/ Use of RSVP to establish the reverse path The RSVP protocol uses 'soft states'. So, in order to maintain the path for the time of the Internet session, the host will continue, at regular time interval, to send RSVP 'path keep alive' messages. As soon as the foreign connectivity is no longer required (the foreign IP address is released) the host will send and RSVP 'path tear down' in order to remove the reverse path. NB: In the case where the operated network has multiple connections to Realm2, the host could setup a reverse path for each of the routers connected to this realm. Those multiple reverse paths may be useful when more robustness is required. Indeed, as there is redundancy in the way to reach the host (from Realm2's network), if the edge router on the current shortest path (from Realm2's network towards the host) fails, Realm2's network is still able to forward traffic to the host using an alternative path. The principal advantage of this mechanism compared to OMRD is that only a minimum set of routers have to be informed about the location of the host, enabling fast establishment of the reverse path. Moreover, the mechanism inherits from RSVP the maintenance of the path. The drawbacks of this mechanism is that the network must be RSVP enabled and that both RSVP client and RSVP capable routers must be able to manage the new Object. Zaccone, et al. Expires September 3, 2000 [Page 7] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 6. Conclusions Delivering traffic, issued from a foreign realm, to host on the operated network may be realised like any other traffic as soon as routers have the required routing information available. Some mechanisms described here may be deployed independently of other technologies. Whereas some take as consideration the deployment of other technologies, such as multicast and RSVP, to argue for scalability and fast deployment by the inheritance of their characteristics. By using a native transport scheme, a transport technology is not required anymore to split the route, between a foreign host and a host on the local realm, in two and therefore braking the end-to-end principle of the Internet connectivity. 7. Security Considerations Security considerations will be added in later versions of this draft. 8. Acknowledgements The authors would like to thank Peter de Schrijver, Paloma de la vallee for discussions related to this document. 9. References [TRANSP-FRAM] C. Zaccone, Y. T'Joens, B. Sales, "Framework for end-2-end native transport", Internet Draft , March 2000. [OSPF] J. Moy, "OSPF version 2", Internet RFC 2328, April 1998. [OSPF_V6]R. Coltun, . Ferguson, J. May, " OSPF for IPv6", RFC2740. [PIM] S. Deering, D. Estrin, D. Farinacci, M. Handley, A. Helmy, Van Jacobson, C. Liu, P. Sharma, D. Thaler and L. Wei, " Protocol Independent Multicast-Sparse Mode (PIM-SM): Motiva- tion and Architecture", Internet Draft , August 1998. Zaccone, et al. Expires September 3, 2000 [Page 8] Internet Draft draft-zaccone-nat-transport-02.txt March 3, 2000 Authors Addresses Carmelo Zaccone Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-8344 Fax : 32-3-240-9932 E-mail: Carmelo.Zaccone@Alcatel.be Yves T'Joens Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-7890 Fax : 32-3-240-9932 E-mail: Yves.Tjoens@Alcatel.be Bernard Sales Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-9574 Fax : 32-3-240-9932 E-mail: Bernard.Sales@Alcatel.be Zaccone, et al. Expires September 3, 2000 [Page 9]