Network Working Group Sina Mirtorabi Internet Draft Abhay Roy Expiration Date: July 2005 Padma Pillay-Esnault File name: draft-mirtorabi-ospf-ud-link-00.txt Acee Lindem Peter Psenak Cisco Systems January 2005 Support of unidirectional links in OSPFv2 draft-mirtorabi-ospf-ud-link-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. Mirtorabi et al. [Page 1] Internet Draft MT-OSPF January 2005 Abstract This document describes how to support unidirectional links in OSPF and addresses its challenges. Unidirectional link routing (UDLR) describes a link-layer tunneling mechanism in order to abstract the network layer from unidirectional links and makes it transparent to routing protocols. Although this solution can be used, it can be cumbersome for user due to configured tunnels and generates extra overhead for control packets and encapsulation of tunnels. This document proposes the necessary extensions to OSPF in order to support unidirectional links. 1. Motivation There are network deployments where a link could be only unidirectional but we still need routing protocols to forward traffic over it. UDLR [1] emulates full bidirectional connectivity between nodes that are directly connected by a unidirectional link. The receiver uses a link-layer tunneling mechanism to forward datagrams to send-only interface over an alternative path. The tunnelling mechanism come at a significant cost, there is a configuration overhead and the tunnels generate extra overhead for control and data packets. Alternative solution proposed in this document is to run OSPF directly over unidirectional links and therefore avoid any tunneling. The following sections describe the extension to OSPF [2] for supporting unidirectional links. 2. Terminology Unidirectional link (ud-link): A one way transmission link which can either transmit or receive. Send-only interface: A router's interface that can only transmit. Receive-only interface: A router's interface that can only receive. Bidirectional interface: A typical communication interface that can both send and receive packets. In the following section a bidirectional interface is simply called interface. 3. Problem definition The operations of OSPF over unidirectional links are divided into three parts : a) Establishing adjacency over ud-link b) Flooding over ud-links c) Advertising adjacency over ud-links and SPF Mirtorabi et al. [Page 2] Internet Draft MT-OSPF January 2005 4. Assumption In the following section we assume a topology where A and B are two nodes and the link L(ab) is unidirectional from A to B. This means that node A's interface to link L(ab) is send-only and the node B's interface to link L(ab) is receive-only. Further there is an alternative path from B to A which in general is a multi-hop path. L(ab) F------A------>B-----C | | E--------------------D 5. Establishing adjacency over ud-links Contrary to a regular bidirectional links where Hellos are sent over the common interface between the two nodes, for ud-links Hellos are sent through two different paths. The send-only end-point node of a ud-link will receive Hello from receive-only end-point node of the ud-link via the alternate bidirectional path. Hence the send-only end-point need to process the unicast hello received on other interfaces to determine the corresponding ud-link. For numbered interfaces attached to a ud-link, the Hello's source IP address is used to associate a Hello to the corresponding ud-link interface. On multi-access ud-links only NBMA and point-to-multipoint are supported.For unnumbered interfaces, two methods are described to associate a Hello received to the corresponding ud-link interface. 5.1 Hello packets over numbered ud-links For numbered ud-links a neighbor is identified by its IP address. If the interface is send-only, the Hellos are sent directly over the interface as specified in OSPF [2]. On point-to-point the Hellos are sent to ALLSPFRouter and on NBMA and point-to-multipoint, the Hellos are sent to the unicast neighbor's IP address. If the interface is receive-only, the Hellos need to be sent over an alternative path to the remote node provided that such a path exists. In this case the Hellos are sent unicast to neighbor's IP address as long as there is an intra-area path to the remote neighbor IP address. The source IP address is always set to the receive-only interface's IP address (and not the outgoing interface to reach the remote node) because the source IP address is used on the send-only interface node to associate the Hello to the correct neighbor. Mirtorabi et al. [Page 3] Internet Draft MT-OSPF January 2005 In particular, the neighbor source IP address (i.e. receive-only IP address) in OSPF control packet MUST match with a configured IP address on the send-only interface router which correspond to an adjacency over that interface. 5.2 Hello packets over unnumbered ud-links For unnumbered ud-links, if a neighbor can be identified by an IP address, that is, a local IP address can be used to uniquely identify the interface (provided that such an address is available or can be configured) then Hello packet over unnumbered link is the same as described in section 5.1. If neighbor cannot be identified by an IP address (there are not sufficient local IP address or cannot be configured), then a neighbor should be identified by the combination of router ID and local interface-ID. The interface-ID could be carried in LLS [3]. This option will not be defined at this time, as the first option may be acceptable. 5.3 Adjacency over ud-links Once two neighbors reach the 2Way state, they will synchronize their database as specified in OSPF [2]. For Send-only interface, OSPF control packets are sent directly over the ud-link. If the network type is point-to-point, the control packets are sent multicast, otherwise for NBMA and point-to-multipoint the packet are sent unicast. For receive-only interface, OSPF control packet are sent via an alternative intra-area path provided that such a path exist. Independently of the network type the control packets are sent unicast. 6. Flooding over ud-links Flooding is performed over adjacencies associated with the corresponding ud-link interfaces as specified in OSPF [2]. For send-only interface the packets are directly sent over ud-link interface and for receive-only interface the packets are sent indirectly following the shortest intra-area path to the remote node. Flooding reduction [4] or DC [5] can be used in order to reduce the flooding over ud-links. Note that if ud-link is considered as DC [5] and the alternative path between receive-only and send-only disappear, constant flooding over ud-link could occur unless an implementaion limit the number of retransmissions over an adjacency or support probing as defined in [6]. Mirtorabi et al. [Page 4] Internet Draft MT-OSPF January 2005 7. Advertising adjacency over ud-links and SPF An adjacency is advertised in router or network LSA when the router reaches the FULL state with its neighbors. when the interface is receive-only, the adjacency should be advertised with max metric 0xFFFF. This would prevent a router to use the unidirectional link from receive-only to send-only direction provided that a shorter path exist. However the max metric does not guarantee the ud-link to be used (see section 8). Therefore We introduce an extension in order to consider the max metric unreachable during SPF when all routers are capable of this extension. If some routers do this modified behavior and others don't, we have possibilities of introducing routing loops. For that a new UnreachCapability is introduced which MUST be set by routers who support this modified behavior. Special handling for UnreachMetric happens ONLY if all the routers in the area support UnreachCapability. The shortest path calculation section 16.1 of [2] is modified to introduce a new step (a') before (a). (a') If the link metric is UnreachMetric and arRtrsNoUnreachCapability (see appendix C) is zero, examine the next link in V's LSA. (a) If this is a link to a stub network, examine the next link in V's LSA. Links to stub networks will be considered in the second stage of the shortest path calculation. A router announces its UnreachCapability by setting a new U-bit in its router LSA, see appendix D. In a mixed environment where some routers do not have the UnreachCapability (arRtrsNoUnreachCapability is non-zero) normal SPF will be performed. However if the shortest intra-area path from receive-only to send-only is through the ud-link, i.e. the total alternative path's cost is more than 0xffff, traffic could be blackholed as packet cannot be sent over ud-link from receive-only to send-only. In order to avoid that if the receive-only router determines through its SPF that the shortest path to the Send-only is over the ud-link AND arRtrsNoUnreachCapability is non-zero then it MUST not advertise the link in router-lsa. Mirtorabi et al. [Page 5] Internet Draft MT-OSPF January 2005 Note that if the above is not performed, when the shortest path from receive-only to send-only is through the ud-link, Hello cannot be sent and the adjacency will be down. Once the adjacency is down, the alternative path's cost will become the shortest path and the adjacency will be brought up and an adjacency is advertised over ud-link with 0xffff. This will make the shortest path to switch through the direct link and the adjacency will flap constantly. 8. Backward Compatibility issues The extension for supporting unidirectional links as specified in this memo is required for routers attached to such a link. The extension to SPF for max metric use UnreachCapability to make sure that the SPF modifications is performed only when all the routers in an area claim to understand it. This allows an incremental deployment by upgrading only routers attached to ud-links. However it should be noted that when the shortest intra-area path from receive-only to send-only is equal to max metric (0xffff), that is the alternative intra-area path's cost from receive-only to send-only interface is more than 0xffff, the adjacency will not be advertised therefore the ud-links will not be used for forwarding as the back link check would fail. In such a case the extension to SPF is required to remedy the problem which should be supported by all routers in the area. 9. Layer 2 consideration On multi-access links (NBMA and point-to-multipoint networks) OSPF control packet are sent unicast over the ud-link. However this requires that a layer 3 to layer 2 mapping is available in order to send a packet from send-only to receive-only interface. Because of the unidirectional nature of the link, legacy layer 3 to layer 2 mapping such as ARP [7] will not function. Therefore a manual mapping is required for layer 3 to layer 2 address. Optionally such a mapping could be carried using opaque LSA [8], however this memo does not define such an extension at this time. 10. Security Considerations The mechanism described in this document does not modify security aspects of the OSPF routing protocol. 11. References [1] Duros, E., and al, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001. [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [3] Zinin, A., Friedman, B., Roy, A., Nguyen, L. and D. Yeung, "OSPF Link-local Signaling", Work in progress, September 2004 Mirtorabi et al. [Page 6] Internet Draft MT-OSPF January 2005 [4] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [5] Pillay-Esnault, P., "OSPF Refresh and Flooding Reduction in Stable Topologies", Work in progress, June 2003. [6] Rao, S., Zinin, A., Roy A., "Detecting Inactive Neighbors over OSPF Demand Circuits (DC)", RFC 3883, October 2004. [7] Braden, R., editor, "Requirements for Internet Hosts communication Layers", STD 3, RFC 1122, USC/Information Sciences [8] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. Appendix A. Configurable Parameters This memo defines two configuration parameters in interface data structure Send-only Indicates that the interface is capable only to transmit packet over that interface. The extension to support OSPF over such interface is specified in this memo. Receive-only Indicates that the interface is capable only to receive packet over that interface. The extension to support OSPF over such interface is specified in this memo. Appendix B. Architectural Constants This memo proposes one architectural constant. The interpretation of the value is conditional to all routers in an area being able to understand UnreachCapability. UnreachMetric The link metric value which make a link unreachable to be considered for transit in SPF. The value of UnreachMetric is set to 65535. Appendix C. Area Parameters This memo defines two parameters in area data structure unreachCapability Indicates whether or not a router can understand and compute shortest path tree using UnreachMetric. Mirtorabi et al. [Page 7] Internet Draft MT-OSPF January 2005 arRtrsNoUnreachCapability This is a counter to keep track of the number of routers in an area, which do not support UnreachCapability. This make sure that all routers in the area support UnreachCapability before special handling for links with UnreachMetric. Appendix D. Router LSA A new bit (U) is defined in Router LSA in order to announce unreachCapability. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Nt|W|V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | TOS 0 metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | U-bit If this bit is set in router-LSA, this router is capable of generating and processing UnreachMetric as specified in section 7. Mirtorabi et al. [Page 8] Internet Draft MT-OSPF January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Mirtorabi et al. [Page 9] Internet Draft MT-OSPF January 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mirtorabi et al. [Page 10]