idnits 2.17.1 draft-halpern-forces-lfblibrary-vpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.3 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 511. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Negative revision number: the document name given in the document, 'draft-halpern-forces-lfblibrary-vpn--00', seems to have a negative revision number (it ends with '--00'). See https://www.ietf.org/id-info/1id-guidelines.txt, section 7, on how to construct a good document name. == Mismatching filename: the document gives the document name as 'draft-halpern-forces-lfblibrary-vpn--00', but the file name used is 'draft-halpern-forces-lfblibrary-vpn-00' == 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 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 25 instances of too long lines in the document, the longest one being 31 characters in excess of 72. ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 52 has weird spacing: '...nitions in...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 16, 2007) is 6308 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) == Unused Reference: '1' is defined on line 453, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 458, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3654 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3746 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- No information found for draft-ietf- - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-16) exists of draft-ietf-forces-model-06 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft J.Halpern 3 Expires: July 2007 Self 4 Huaiyuan Ma 5 Huawei Technologies Co., Ltd 6 January 16, 2007 8 A VPN Library for use with the ForCES Protocol and Model 9 draft-halpern-forces-lfblibrary-vpn--00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 This document may only be posted in an Internet-Draft. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on July 16, 2007. 38 Abstract 40 The forwarding and Control Element Separation (ForCES) protocol 41 defines a standard communication and control mechanism through which 42 a Control Element (CE) can control the behavior of a Forwarding 43 Element (FE). That control is accomplished through manipulating 44 attributes of Logical Function Blocks (LFBs), whose structure is 45 defined in a model RFC produced by the working group. In order to 46 build an actual solution based on this protocol, defining a set of 47 Logical Function Block definitions that can be instantiated by FEs 48 and controlled by CEs is welcome. A base library definition of LFBs 49 is already given in library [5]. VPN (Virtual Private Network) 50 services, as a kind of important services widely employed in Internet, 51 will certainly be implemented in routers using this protocol. This 52 document provides an initial set of VPN LFB definitions in 53 particular, a set of tunnel encapsulator and decapsulator LFBs. It is 54 anticipated that additional VPN-related LFB definitions like L2VPN, 55 L3VPN can be defined over time. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119. 63 Table of Contents 65 1. Introduction................................................3 66 2. Tunnel Definitions..........................................3 67 2.1. GRE Tunnel Definitions.................................3 68 3. Security Considerations.....................................11 69 4. Acknowledgments.............................................11 70 5. References..................................................11 71 5.1. Normative References...................................11 72 5.2. Informative References.................................12 73 Author's Addresses.............................................12 74 Intellectual Property Statement................................12 75 Disclaimer of Validity.........................................13 76 Copyright Statement............................................13 77 Acknowledgment.................................................13 79 1. Introduction 81 In a solution using ForCES protocol, Control Elements (CEs) can 82 control the behavior of Forwarding Elements (FEs) through 83 manipulating attributes of Logical Function Blocks (LFBs). LFB's 84 structure and abstract semantics is defined in Model [6]. That 85 document also defines a single LFB Class for gaining access to FE 86 properties including the set of LFBs and their interconnection. A LFB 87 class is defined to manipulate the protocol properties of the FE in 88 the protocol [4]. 90 In I-D draft [5], a set of LFBs which are necessary to implement 91 basic forwarding process are defined. This draft is intended to 92 define an initial set of LFBs for a kind of important Internet 93 service, Virtual Private Network (VPN). It is expected that other 94 VPN-related definitions will be developed over time. 96 2. Tunnel Definitions 98 2.1. GRE Tunnel Definitions 100 GRE tunnel specification and its extension are described in RFC 2784 101 and RFC 2890 respectively. A GRE tunnel is composed of three parts: 102 outer delivery header, followed by a GRE header which is followed by 103 a payload packet. The format of outer delivery header is determined 104 by the corresponding delivery protocol, IPv4 or IPv6. In GRE header, 105 there are two important optional fields: one is called GRE key which 106 is intended to be used for identifying an individual traffic flow 107 within a tunnel; the other is called Sequence Number, the Sequence 108 Number MUST be used by the receiver to establish the order in which 109 packets have been transmitted from the encapsulator to the receiver. 110 The intended use of the Sequence Field is to provide unreliable but 111 in-order delivery. The payload packet would be IPv4, IPv6 etc. 113 When forwarding an IP packet in a next-hop applicator LFB, the 114 matched FIB entry indicates the packet should be transmitted over a 115 GRE tunnel and a correct tunnel index can be found out in the FIB 116 entry. The original packet will be fed to GRE tunnel encapsulator 117 with tunnel index as meta-data together in the downstream forwarding 118 process. Tunnel index points to the correct tunnel entry in tunnel 119 configuration table which stores the information of each tunnel. Each 120 tunnel entry maintains a management flag called "TunnelState" 121 indicating whether the current tunnel is administratively up. 123 GRE tunnel maintains a fragmentation permitted flag. Before 124 encapsulating a payload packet GRE tunnel encapsulator will check the 125 size of that payload packet against MTU. If the size of tunnelled 126 packet is larger than MTU and at this moment that fragmentation 127 permitted flag should be checked, if that flag is set, then chop the 128 original packet into small packets with appropriate size, otherwise, 129 send ICMP message to notify the appropriate receiver of some error. 130 If the delivery protocol is IPv4, then the format of outer delivery 131 header would be IPv4, otherwise, it would be IPv6. 133 Once a IP packet with GRE is produced from an output port from GRE 134 tunnel encapsulator, a meta-data called "NextHopReference" which 135 points to the index of correct FIB entry is accompanied at the same 136 time, that is, an alias entry pointing to the next-hop table so that 137 it can use the predetermined route to the tunnel end-point. 139 When a classifier LFB identifies the incoming packet is an IP packet 140 with GRE at the GRE tunnel exit point, it will feed that packet to 141 the GRE tunnel decapsulator, which will find out the correct tunnel 142 index which maintains a local VPN ID field, the GRE tunnel 143 decapsulator then strips off the outer delivery header and GRE header 144 and feed it to the forwarding-related LFB with local index ID as 145 meta-data indicating which VPN that payload packet belongs to. 147 The actual GRE tunnel LFB class is defined as below. 149 150 151 152 153 NextHopIndex 154 155 An index used by the next hop table. 156 Typically stored in and generated as metadata by 157 the longest-prefix-match LFB 158 159 int32 160 161 162 VPNID 163 164 An ID used to provide context for 165 VPN specific Packet processing. 166 167 int32 168 169 170 GRETunnelTableType 171 172 GRE tunnel configuration table 173 Each table entry describes a single GRE tunnel. 174 The table Index is input meta-data for the encapsulator. 175 176 177 178 179 TunnelValid 180 181 It is enabled or disabled by FIB indicating whether the current tunnel is permitted to 182 be used in forwarding process. 183 184 boolean 185 186 187 FragmentationPermitted 188 189 it indicates whether it permits fragmentation when the size of a packet exceeds 190 the tunnel's MTU. 191 192 boolean 193 194 195 ChecksumNeeded 196 197 it indicates whether a checksum is needed. 198 199 boolean 200 201 202 PacketType 203 ...needs definition ... 204 ... probably for decapsulator error checking? ... 205 206 207 SrcAddr 208 209 IP Address for local end of tunnel 210 211 IPAddress 212 213 214 DstAddr 215 216 Address for remote End of Tunnel 217 218 IPAddress 219 220 221 GREKey 222 223 Key for this specific GRE Tunnel 224 The presence of this element indicate this tunnel uses 225 keyed GRE format. 226 227 228 int32 229 230 231 NextHopReference 232 233 Reference to the correct NextHopIndex 234 This points to a LPM where the next hop is maintained. 235 The information is put in the encapsulator meta-data. 236 237 NextHopIndex 238 239 240 MTU 241 242 Maximum Transmit Unit Used in conjunction with the flags 243 to decide if large packets should be encapsulated, fragmented, 244 or errored. 245 246 uint32 247 248 249 LocalVPNID 250 251 VPN ID used by decapsulator as generated 252 meta-data 253 254 VPNID 255 256 257 TunnelState 258 259 It indicates whether the current tunnel is administratively up or down. 260 261 Boolean 262 263 264 SequencingNeeded 265 266 it indicates whether a sequence field to differentiate different traffic flows in a 267 tunnel is needed. 268 269 boolean 270 271 272 SequenceNumber 273 274 a sequence field to differentiate different traffic flows in a tunnel. 275 276 277 int32 278 279 280 Checksum 281 282 The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit 283 words in the GRE header and the payload packet. 284 285 286 int16 287 288 289 290 291 292 293 294 GRE_Encapsulator 295 296 It specifies how to encapsulate an IP packet so that it can be transmitted over GRE tunnel. 297 298 0.0 299 300 301 PacketIn 302 303 Normal packet in. 304 305 306 307 IPv4 308 IPv6 309 310 311 Tunnel_Index 312 313 314 315 316 317 318 PacketOut 319 320 IP packet with GRE 321 322 323 324 GREFrame 325 326 327 NextHopReference 328 329 330 331 332 FailOutput 333 334 error prompt information to indicate whether some operations like fragmentation are 336 permitted. 337 338 339 340 taggedFrame 341 342 343 errorid 344 345 346 347 348 349 350 GRETunnelTable 351 352 Table of GRE Tunnels supported by this 353 encapsulator 354 355 GRETunnelTableType 356 357 358 359 when fowarding a IP packet, a matching FIB entry has a GRE tunnel flag which indicates it 360 should be transmitted over a GRE tunnel, then according to the constrains, TTL, MTU, 361 fragmentation flag etc in the GRE tunnel entry to encapsulate a IP packet in its payload 362 part. 363 364 365 366 GRE_Decapsulator 367 368 It specifies the procedure how to decapsulate a tunnelled packet. 369 370 0.0 371 372 373 PacketIn 374 375 A IP packet with GRE. 376 377 378 379 GREFrame 380 381 382 383 384 385 386 PacketOut 387 388 original packet output 389 390 391 392 IPv4 393 IPv6 394 395 396 LocalVPNID 397 398 399 400 401 FailOutput 402 403 error prompt information generated when a GRE packet cannot match a GRE tunnel 404 state 405 406 407 408 taggedFrame 409 410 411 errorid 412 413 414 415 416 417 418 GRETunnelTable 419 420 Reference to the GRE Tunnel Table this decapsulator uses 421 which is stored in the corresponding encapsulator. 422 423 GRETunelTableType 424 425 426 427 Once the classifier has determined the content of an incoming packet is GRE, it will be fed 428 to a GRE decapsulator, which can achieve the local VPN ID to which the packet belongs and 429 strip off the outer IP header and GRE shim, at the same time, treat local VPN ID as meta- 430 data and then feed it and original packet to the down-stream LFBs. 431 432 433 434 436 3. Security Considerations 438 These definitions if used by an FE to support ForCES create 439 manipulable entities on the FE, Manipulation of such objects can 440 produce almost unlimited effects on the FE. FEs should ensure that 441 only properly authenticated ForCES protocol participants are 442 performing such manipulations. Thus, largely, the security issues 443 with this protocol are defined in Protocol [2]. 445 4. Acknowledgments 447 Thanks Zengjie,Kou for providing some comments. 449 5. References 451 5.1. Normative References 453 [1] Khosravi, et al. Requirements for Separation of IP Control and Forwarding, 454 RFC 3654, November 2003. 456 [2] L. Yang, et al. ForCES Architectural Framework, RFC 3746, April 2004. 458 [3] Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., and S. Blake, 459 "ForCES Forwarding Element Model", Feb. 2005. 461 [4] A. Doria, et al. ForCES Protocol Specification, draft-ietf- forces- 462 protocol-06.txt, December 2005. 464 [5] Joel M.Halpern, A base Library for use with the ForCES Protocol 465 and Model, draft-halpern-forces-lfblibrary-base-01.txt, March, 466 2006 468 [6] L.Yang, et al. ForCES Forwarding Element Model, draft-ietf- 469 forces-model-06.txt 471 5.2. Informative References 473 Author's Addresses 475 Joel M. Halpern 476 Self 477 P. O. Box 6049 478 Leesburg, VA 20178 479 US 481 Huanyuan Ma 482 Huawei Technologies Co., Ltd 483 mahuaiyuan@huawei.com 485 Zengjie Kou 486 Huawei Technologies Co., Ltd 487 kouzengjie@huawei.com 489 Intellectual Property Statement 491 The IETF takes no position regarding the validity or scope of any 492 Intellectual Property Rights or other rights that might be claimed to 493 pertain to the implementation or use of the technology described in 494 this document or the extent to which any license under such rights 495 might or might not be available; nor does it represent that it has 496 made any independent effort to identify any such rights. Information 497 on the procedures with respect to rights in RFC documents can be 498 found in BCP 78 and BCP 79. 500 Copies of IPR disclosures made to the IETF Secretariat and any 501 assurances of licenses to be made available, or the result of an 502 attempt made to obtain a general license or permission for the use of 503 such proprietary rights by implementers or users of this 504 specification can be obtained from the IETF on-line IPR repository at 505 http://www.ietf.org/ipr. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights that may cover technology that may be required to implement 510 this standard. Please address the information to the IETF at 511 ietf-ipr@ietf.org. 513 Disclaimer of Validity 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 518 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 519 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 520 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Copyright Statement 525 Copyright (C) The Internet Society (2007). 527 This document is subject to the rights, licenses and restrictions 528 contained in BCP 78, and except as set forth therein, the authors 529 retain all their rights. 531 Acknowledgment 533 Funding for the RFC Editor function is currently provided by the 534 Internet Society.