idnits 2.17.1 draft-ohba-tagsw-vs-csr-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-24) 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 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 30 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 21 instances of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 292 looks like a reference -- Missing reference section? '2' on line 296 looks like a reference -- Missing reference section? '3' on line 300 looks like a reference -- Missing reference section? '4' on line 304 looks like a reference -- Missing reference section? '5' on line 308 looks like a reference -- Missing reference section? '8' on line 320 looks like a reference -- Missing reference section? '6' on line 312 looks like a reference -- Missing reference section? '7' on line 316 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Comparison of Tag Switching and CSR April, 1997 3 Multi-Protocol Label Switching WG Yoshihiro Ohba 4 Internet Draft Toshiba 5 Expiration Date: October 1997 6 Hiroshi Esaki 7 Toshiba 9 Yasuhiro Katsube 10 Toshiba 12 April 1997 14 Comparison of Tag Switching and Cell Switch Router 15 draft-ohba-tagsw-vs-csr-00.txt 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 Tag Switching and Cell Switch Router are layer integration 38 technologies between L2 and L3 to provide high-speed cut-through 39 mechanisms for L3 packet transfer by mapping between L3 and L2 40 datagram labels. TDP and FANP, used in Tag Switching and Cell Switch 41 Router, respectively, are protocols that notify the mapping 42 information between peer routers. Although the objectives of both 43 technologies are the same, there are several differences in methods 44 for achieving the objective. This memo compares the two technologies 45 and discusses how to merge them. 47 1. Tag Switching 49 In Tag Switching, the mapping is called binding, and the binding is 50 uniquely identified by 32-bit fixed length index called tag. Tags are 52 Y.Ohba, et al. Expires October, 1997 [Page 1] 53 allocated based mainly on destination address to support 54 destination-based routing (of course Tag Switching can support other 55 allocation policies). A destination-based binding is created when the 56 routing protocol running on the TSR creates a new routing table entry. 57 This type of allocation is called "control-traffic-driven." 59 As for tag allocation, Tag Switching allows three modes: downstream 60 tag allocation, downstream tag allocation on demand, and upstream tag 61 allocation. Downstream tag allocation on demand is currently defined 62 for supporting ATM. Hereafter we focus on downstream on demand for the 63 purpose of discussion on tag management over ATM. See [1] for other 64 modes. 66 Tag Switching uses two methods for advertising the mapping between L2 67 and L3 labels. One method is using existing protocol packets, i.e., 68 tags are carried in the protocol messages such as BGP, PIM, and RSVP 69 [2] messages. The other method is using Tag Distribution Protocol 70 (TDP) [3] which is the specialized protocol for distributing tags. TDP 71 is used where the former method is not efficient (e.g., an OSPF area). 73 TDP runs between two Tag Switching Routers (TSRs) over a connection 74 oriented transport layer with guaranteed sequential delivery (e.g., 75 TCP). In other words, one TDP session is established between peer 76 TSRs. A TDP session is kept by sending keep-alive packets periodically 77 to its peer. If a TDP does not see keep-alive packets from its peer 78 within certain interval, the TDP session is deleted. 80 In ATM environment, a tag information exchanged (via TDP) between peer 81 TSRs contains a VPI/VCI of cell header [4], which puts a restriction 82 on Tag Switching that a TSR is not allowed to connect its peer via 83 conventional ATM switches since VPI/VCI is re-written at each ATM 84 switch. 86 When ATM-TSR receives a tag binding request for a certain route from 87 an upstream neighbor ATM-TSR, it creates the binding between incoming 88 tag (VPI/VCI) and the route, and advertises them to the peer that 89 originated the request. The ATM-TSR then requests for an outgoing tag 90 (VPI/VCI) to the next hop for that route. After receiving the binding 91 from the next hop neighbor, the ATM-TSR associates the incoming tag 92 with the outgoing tag, which enables cut-through packet forwarding. 94 Once a binding is created, it is not deleted as long as the route for 95 the corresponding destination is kept unchanged or the TDP session is 96 alive. 98 If a new binding request for a route arrives and there are already 99 some binding(s) for the same route, the ATM-TSR must create a new 100 different incoming tag for the same route and request for a different 101 outgoing tag. This is because packets which have the same destination 103 Y.Ohba, et al. Expires October, 1997 [Page 2] 104 but arrived at different input interfaces cannot be multiplexed onto a 105 single VC unless some non-interleaving scheduling mechanism is 106 supported in the underlying L2 switch. As a result, the bindings are 107 created for each (ingress-TSR, destination address prefix). 109 When a tag binding is no longer needed, the ATM-TSR may delete the 110 binding and notify the next hop. Then the next hop ATM-TSR also 111 destroy the corresponding binding and notify the next hop, and this 112 process is repeated at each ATM-TSR. In this point, we can say that 113 globally synchronized (end-to-end) states are maintained by using TDP. 115 Tag Switching also allows a packet to carry a set of tags, organized 116 as a stack [1,5]. Each tag in a stack corresponds to each routing 117 hierarchy, e.g., BGP and IGP. This enables Tag Switching to scale. 119 2. Cell Switch Router (CSR) 121 In CSR [8], FANP (Flow Attribute Notification Protocol) [6] plays the 122 same role as TDP in Tag Switching. FANP runs between two CSRs over 123 unreliable transport (the current FANP implementation runs over IP 124 with unreserved protocol-id). No FANP level session is established 125 between peer CSRs. 127 To identify the mapping between L3/L2 labels, a CSR allocates a VCID 128 (Virtual Connection IDentifier). FANP can support various types 129 (lengths) of VCIDs depending on L2. Fixed length (12-octet) VCID is 130 defined for ATM, which is composed of 6-octet ESI (End System 131 Identifier) of an ATM end-system address, and 6-octet ID which 132 uniquely identifies VCIDs allocated by the same CSR. The use of VCID 133 instead of VPI/VCI makes CSR independent of topological design. This 134 means that, with VCID negotiation procedure, CSRs can be 135 interconnected through the ATM switches that changes incoming VPI/VCI 136 values to the different outgoing VPI/VCI values. 138 VCIDs are uniquely allocated based mainly on a pair of IP source and 139 destination addresses. We refer to such a pair as a flow. The 140 allocation is made when the first trigger packet arrives. Trigger 141 packet is a packet which contains one of certain TCP/UDP port numbers 142 and certain address pair. This type of allocation is called 143 "data-traffic-driven." 145 As for the VCID management over ATM, current FANP specification 146 supports upstream VCID allocation policy, e.g., after allocating a 147 VCID a CSR advertises the VCID and the corresponding (source, 148 destination) pair to the downstream neighbor CSR, and the receiving 149 CSR installs these information. Since the current CSR implementation 150 is flow-based, the receipt of incoming VCID does not trigger off a new 151 allocation of an outgoing VCID at the receiving CSR. Instead, 152 allocations are always triggered by arrivals of trigger packets. 154 Y.Ohba, et al. Expires October, 1997 [Page 3] 155 After the mapping information for the flow is installed at the 156 downstream CSR, the CSR periodically sends refresh packets to the 157 upstream neighbor as long as there are any packet arrivals for that 158 flow in each period. Refresh packets are sent flow-by-flow. The 159 interval used to send refresh packets is called RefreshInterval. If no 160 data packet arrives within N*RefreshInterval, the mapping information 161 created for the incoming flow and the incoming VC for that flow are 162 deleted. 164 The upstream CSR sets a timer on receiving the first refresh packet 165 from its downstream neighbor. The timer is called Dead Timer, and the 166 value set to Dead Timer is called DeadInterval. The upstream CSR keeps 167 the outgoing VC and the mapping information for that flow as long as 168 it receives a refresh packet from the downstream neighbor before Dead 169 Timer expires. Dead Timer is always reset on receiving a refresh 170 packet before expiration of Dead Timer. If no refresh packet is 171 received within DeadInterval, the CSR deletes the outgoing mapping 172 information and release the outgoing VC for that flow. This means that 173 CSR employs a soft state mechanism in mapping management. Note that 174 our implementation also allows state deletion at any time when a CSR 175 receives a release packet from its downstream neighbor. 177 Unlike Tag Switching, deletion of a state (mapping) for a flow is 178 executed locally, without notifying the deletion that would cause the 179 deletion of entire states for the flow along the path. Hence we can 180 say that local (link-by-link) states are maintained by using FANP. 182 Y.Ohba, et al. Expires October, 1997 [Page 4] 183 Table 1: Comparison of Tag Switching and CSR 184 +-------------------+-------------------------+---------------------------+ 185 | | Tag Switching | CSR | 186 +===================+=========================+===========================+ 187 | Method for | (1) use existing | | 188 | binding info. | protocol packets | use FANP | 189 | delivery | (2) use TDP | | 190 +-------------------+-------------------------+---------------------------+ 191 | Trigger to create | Route change | Arrival of trigger packet | 192 | a state |(control-traffic-driven) | (data-traffic-driven) | 193 +-------------------+-------------------------+---------------------------+ 194 | Unit of state | (ingress-TSR,dst) | (src,dst) | 195 +-------------------+-------------------------+---------------------------+ 196 | Impact of | Not local | Local | 197 | state change | (when TDP is used) | | 198 +-------------------+-------------------------+---------------------------+ 199 | Consistency with | Both deletes old binding immediately | 200 | routing state | when routing state changes. | 201 +-------------------+-------------------------+---------------------------+ 202 | Binding allocation| downstream allocation | upstream allocation only | 203 | policy | (in most cases) | | 204 +-------------------+-------------------------+---------------------------+ 205 | How to deal with | Loop prevention by using| Loop correction | 206 | loops | TDP hopcount or TTL | | 207 | | field in tag stack | | 208 +-------------------+-------------------------+---------------------------+ 209 | Hierarchy support | Yes | No | 210 +-------------------+-------------------------+---------------------------+ 212 3. Comparison 214 We summarize the features of Tag Switching and CSR in ATM environment 215 in Table 1. 217 3.1 Method for binding information delivery 219 There are two methods for Tag Switching to deliver binding 220 information: (1) using existing protocol packets, and (2) using TDP. 221 When method (1) is used, reliability of delivery is realized by the 222 carrying protocol. When method (2) is used, TCP guarantees the 223 reliability. On the contrary, CSR always uses FANP for the binding 224 information delivery. FANP has its own reliable delivery mechanism, 225 used in common with unicast and multicast, over unreliable transport. 227 3.2 Trigger to create a state 229 Y.Ohba, et al. Expires October, 1997 [Page 5] 230 Installation of state with the current CSR is driven by data traffic 231 for the legacy packet traffic. The operation overview for RSVP traffic 232 is given in [7]. In contrast installation of state with tag switching 233 is driven directly by control traffic (e.g., unicast routing updates, 234 RSVP messages, PIM messages). 236 3.3 Unit of state 238 In CSR, a state is created for (src, dst). In Tag Switching, a state 239 is created for (ingress TSR, dst). 241 3.4 Impact of state change 243 When a state change occurs in a TSR with TDP, it causes direct state 244 changes at other TSRs (e.g., by sending TDP_PIE_REMOVE_BIND messages). 245 So, if a TDP session fails in some node, say A, for some reason, the 246 entire bindings for all routes that go through node A are completely 247 deleted from the network and only hop-by-hop packet transfer is 248 permitted for those routes, unless VC merging is not available. On the 249 contrary, changes in state with CSR are purely local, default-VC 250 (hop-by-hop) transfer is carried out only between node A and its 251 neighbor routers. 253 3.5 Consistency with routing state 255 When a routing state changes, both Tag Switching and CSR immediately 256 deletes the old bindings associated to the change, and creates new 257 bindings according to the new routing state. 259 3.6 Binding allocation policy 261 As for binding allocation, Tag Switching employs downstream allocation 262 policy in most cases whereas CSR employs upstream allocation 263 policy. However, downstream allocation seems inapplicable to multicast 264 cut-through on multi-access ATM network using the standard ATM 265 Forum/ITU-T signaling. 267 3.7 Loop detection 269 There are two methods to deal with loops over label switching path: 270 loop correction and loop prevention. In the loop correction, MPLS 271 level loops are allowed to be set up over a label switching path, and 272 data may be transmitted over the loops, but the loops is later 273 detected and closed. On the contrary, in the loop prevention, data is 274 never transmitted over a MPLS level loop. 276 CSR has a loop correction mechanism in which MPLS level loops 277 disappear as soon as the related L3 level loops disappear. 278 Tag Switching has two loop prevention mechanisms. 280 Y.Ohba, et al. Expires October, 1997 [Page 6] 281 One method is using TDP level hop count which is carried in TDP 282 messages. Another method is using TTL field of tag 283 stack which is prepended to each IP packet [5]. 285 3.8 Hierarchy support 287 The idea of hierarchical tag support in Tag Switching is good in terms 288 of scalability. 290 References 292 [1] Y. Rekhter et al., 293 "Cisco System's Tag Switching Architecture Overview," 294 Internet RFC 2105, Feb. 1997. 296 [2] F. Baker, 297 "Use of Flow Label for Tag Switching," Internet Draft, 298 draft-baker-flow-label-00.txt, Oct. 1996. 300 [3] P. Doolan et al., 301 "Tag Distribution Protocol," Internet Draft, 302 draft-doolan-tdp-spec-00.txt, Sep. 1996. 304 [4] B. Davie et al., 305 "Use of Tag Switching With ATM," Internet Draft, 306 draft-davie-tag-switching-atm-01.txt, Jan. 1997. 308 [5] E. Rosen et al., 309 "Tag Switching: Tag Stack Encodings," Internet Draft, 310 draft-rosen-tag-stack-01.txt, March 1997. 312 [6] K. Nagami et al., 313 "Flow Attribute Notification Protocol (FANP) Specification," 314 Internet Draft, draft-rfced-info-nagami-00.txt, Nov. 1996. 316 [7] Y. Katsube et al., 317 "Interoperation Scenario Between Distinct Types of Cut-through," 318 Internet Draft, Apl. 1997. 320 [8] Y. Katsube et al., 321 "Toshiba's Router Architecture Extensions for ATM : Overview", 322 Internet RFC 2098, Feb. 1997. 324 Y.Ohba, et al. Expires October, 1997 [Page 7] 325 Authors 327 Yoshihiro Ohba 328 R&D Center, Toshiba Corporation, 329 1 Komukai-Toshiba-cho, Saiwai-ku, 330 Kawasaki, 210, Japan 331 Tel: +81-44-549-2238 332 Fax: +81-44-520-1806 333 Email: ohba@csl.rdc.toshiba.co.jp 335 Hiroshi Esaki 336 Computer and Network Division, 337 Toshiba Corporation, 338 1-1-1 Shibaura, 339 Minato-ku, 105-01, Japan. 340 Tel: +81-3-3457-2536 341 Fax: +81-3-5444-9234 342 Email: hiroshi@isl.rdc.toshiba.co.jp 344 Yasuhiro Katsube 345 R&D Center, Toshiba Corporation, 346 1 Komukai-Toshiba-cho, Saiwai-ku, 347 Kawasaki, 210, Japan 348 Tel: +81-44-549-2238 349 Fax: +81-44-520-1806 350 Email: katsube@isl.rdc.toshiba.co.jp 352 Acknowledgment 354 We appreciate Yakov Rekhter and Paul Doolan of Cisco Systems Inc. 355 for giving us comments on this document.