idnits 2.17.1 draft-ietf-udlr-dtpc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9656 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 126 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hidetaka Izumiyama 3 Internet-Draft Akihiro Tosaka 4 WIDE project 5 November 1997 7 Dynamic Tunneling Path Configuration for Uni-directional Link Routing 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.nTermet (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 The idea to use unidirectional link(UDL) routing without any 32 modifications of current routing protocols is described in [1], but 33 any dynamic tunneling path configuration technique was not 34 described. This document describe the dynamic tunneling path 35 configuration for UDL routing. 37 1.Approach 39 In the UDLR tunneling approach[1], any tunnel mechanism can be used 40 for the back path to emulate a BDL in combination with the UDL under 41 consideration. In the case when the UDL down due to, for example, 42 transmitter failure, Receiver (not Receiver site) failure, or 43 satellite failure, the back path should be shutdown when a dynamic 44 routing protocol is in use. Otherwise, any packets whose 45 destinations are around the Receiver are routed to the Feed and then 46 sent it to the tunnel. This may result sub-optimal routing (also 47 introduce the header overhead). 49 In order to avoid this, the Feed have to send some control packet 50 periodically (link-level hello) to the Receiver. The packet is 51 delivered to the VIF layer and not delivered to its upper layer. 53 When the VIF does not receive the hello from the Feed, for example a 54 few minutes, the VIF should be declared down to its upper layer. In 55 this state, any packets should not be send over the VIF tunnel. 57 In order to realize such a issue, we would propose to use two type 58 of tables : 60 Address Assign Table(AAT) 62 This table is used to maintain the Receiver's UDL IP address and 63 UDL MAC address. Feed can also use this table to get UDL MAC 64 address of each Receiver. 66 Feed IP address on UDL 67 Netmask of UDL 68 Number(n) of Receivers 69 n * [BDL IP address,UDL IP address,UDL MAC address] 71 Tunneling Path Table(TPT) 73 This table is used to maintain the tunnel path information. 75 src BDL IP address 76 Number(n) of tunnels(Feed: n >= 1, Receiver: n = 1) 77 n * [dst BDL IP address,dst UDL IP address,Dead Interval] 79 Feed holds a AAT and its TPT. Each Receive holds its TPT. 81 2.Messages 83 2.1.Hello message 85 The Feed sends the hello message via UDL when hello interval timer 86 expires. Proposed hello interval for several kilo-bps or higher UDR 87 is 10 sec and corresponding dead interval is 40 sec. 89 Hello message has following information : 91 Feed IP address on UDL 92 Netmask of UDL 93 Dead Interval 94 Number of IP address on BDL at Feed 95 n * [Feed BDL IP address] 97 When a Receiver get a hello message from the Feed, the Receiver can 98 establish a backchannel tunnel to the one of the BDL IP addresses 99 shown in the hello. The criteria of choosing IP address is out of 100 scope of this document, however, it is likely to choose nearest one 101 if the VIF can access the routing table metrics. 103 When a Receiver does not listen the hello packet from particular 104 Feed for more than dead-interval period specified in the last hello 105 message, the VIF in the Receiver has to declare the VIF "down" and 106 any packets directed to the VIF should be discarded. The VIF respond 107 the sender with ICMP host unreachable. 109 2.2.Reply message 110 When Feed get reply message through BDL interface from a Receiver, 111 Feed update the record of AAT. Feed also update his TPT and 112 establish the tunnel to the Receiver. 114 Reply message has following information : 115 Receiver BDL IP address 116 Receiver UDL MAC address 117 Feed BDL IP address 118 (Receiver wants to use this as the end point of tunnel) 120 3.Security Issues 122 Security issues are not discuss in this memo. 124 4. Bibliography 126 [1] Hidetaka Izumiyama,Akihiro Tosaka,Akira Kato 127 "Uni-directional Link Routing with IP tunneling approach" 128 Intenet Draft, 129 April 1997. 131 Author's Address 133 Hidetaka Izumiyama Phone:+81-3-5511-7568 134 Japan Satellite Systems Inc. Email:izu@jcsat.co.jp 135 Toranomon 17 Mori Bldg.5F 136 1-26-5 Toranomon, Minato-ku 137 Tokyo 105 Japan 139 Akihiro Tosaka voice: +81-446-49-1094 140 WIDE Project Karigome Internet email: tosaka@sfc.wide.ad.jp 141 Reserch Center 142 5862, Endo, Fujisawa-shi, 143 Kanagawa-ken, 252, Japan.