idnits 2.17.1 draft-rosen-mpls-lan-encaps-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-25) 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 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([4], [1,2,3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 78: '... MUST...' RFC 2119 keyword, line 83: '... MUST NOT...' RFC 2119 keyword, line 88: '... SHOULD...' RFC 2119 keyword, line 94: '... MAY...' RFC 2119 keyword, line 98: '...lude this option MUST be prepared to i...' (4 more instances...) 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 9658 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-00 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-01 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-00 Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Yakov Rekhter 4 Expiration Date: May 1998 Daniel Tappan 5 Dino Farinacci 6 Guy Fedorkow 7 Cisco Systems, Inc. 9 Tony Li 10 Juniper Networks, Inc. 12 Alex Conta 13 Lucent Technologies 15 November 1997 17 MPLS Label Stack Encoding on LAN Media 19 draft-rosen-mpls-lan-encaps-00.txt 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 36 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 37 ftp.isi.edu (US West Coast). 39 Abstract 41 ''Multi-Protocol Label Switching (MPLS)'' [1,2,3] requires a set of 42 procedures for augmenting network layer packets with ''label stacks'', 43 thereby turning them into ''labeled packets'' [4]. Routers which 44 support MPLS are known as ''Label Switching Routers'', or ''LSRs''. In 45 order to transmit a labeled packet on a particular data link, an LSR 46 must support an encoding technique which, given a label stack and a 47 network layer packet, produces a labeled packet. This document 48 specifies the encoding to be used by an LSR in order to transmit 49 labeled packets on LAN data links. 51 Table of Contents 53 1 Introduction ........................................... 2 54 1.1 Specification of Requirements .......................... 2 55 2 Transporting Labeled Packets over LAN Media ............ 3 56 3 Security Considerations ................................ 3 57 4 Authors' Addresses ..................................... 4 58 5 References ............................................. 5 60 1. Introduction 62 "Multi-Protocol Label Switching (MPLS)" [1,2,3] requires a set of 63 procedures for augmenting network layer packets with "label stacks", 64 thereby turning them into "labeled packets" [4]. Routers which 65 support MPLS are known as "Label Switching Routers", or "LSRs". In 66 order to transmit a labeled packet on a particular data link, an LSR 67 must support an encoding technique which, given a label stack and a 68 network layer packet, produces a labeled packet. 70 This document specifies the encoding to be used by an LSR in order to 71 transmit labeled packets on LAN data links. 73 1.1. Specification of Requirements 75 In this document, several words are used to signify the requirements 76 of the specification. These words are often capitalized. 78 MUST 80 This word, or the adjective "required", means that the 81 definition is an absolute requirement of the specification. 83 MUST NOT 85 This phrase means that the definition is an absolute prohibition 86 of the specification. 88 SHOULD 89 This word, or the adjective "recommended", means that there may 90 exist valid reasons in particular circumstances to ignore this 91 item, but the full implications must be understood and carefully 92 weighed before choosing a different course. 94 MAY 96 This word, or the adjective "optional", means that this item is 97 one of an allowed set of alternatives. An implementation which 98 does not include this option MUST be prepared to interoperate 99 with another implementation which does include the option. 101 2. Transporting Labeled Packets over LAN Media 103 The label stack MUST be represented and processed as specified in 104 [4]. 106 Each LAN frame that carries a labeled packet MUST carry exactly one 107 labeled packet. 109 The label stack entries MUST immediately precede the network layer 110 header, and MUST follow any data link layer headers, including, e.g., 111 any VLAN headers, 802.1Q headers, etc. that may exist. 113 The ethertype value 8847 hex is used to indicate that a frame is 114 carrying an MPLS unicast packet. 116 The ethertype value 8848 hex is used to indicate that a frame is 117 carrying an MPLS multicast packet. 119 These ethertype values can be used with either the ethernet 120 encapsulation or the 802.3 SNAP/SAP encapsulation to carry labeled 121 packets. 123 The procedures for processing labeled packets are as specified in 124 [4]. 126 3. Security Considerations 128 Security considerations are not discussed in this document. 130 4. Authors' Addresses 132 Eric C. Rosen 133 Cisco Systems, Inc. 134 250 Apollo Drive 135 Chelmsford, MA, 01824 136 E-mail: erosen@cisco.com 138 Dan Tappan 139 Cisco Systems, Inc. 140 250 Apollo Drive 141 Chelmsford, MA, 01824 142 E-mail: tappan@cisco.com 144 Dino Farinacci 145 Cisco Systems, Inc. 146 170 Tasman Drive 147 San Jose, CA, 95134 148 E-mail: dino@cisco.com 150 Yakov Rekhter 151 Cisco Systems, Inc. 152 170 Tasman Drive 153 San Jose, CA, 95134 154 E-mail: yakov@cisco.com 156 Guy Fedorkow 157 Cisco Systems, Inc. 158 250 Apollo Drive 159 Chelmsford, MA, 01824 160 E-mail: fedorkow@cisco.com 162 Tony Li 163 Juniper Networks 164 3260 Jay Street 165 Santa Clara, CA 95051 166 E-mail: tli@jnx.com 168 Alex Conta 169 Lucent Technologies 170 300 Baker Avenue 171 Concord, MA, 01742 172 E-mail: aconta@lucent.com 174 5. References 176 [1], "A Proposed Architecture for MPLS", 7/97, draft-ietf-mpls-arch- 177 00.txt, Rosen, Viswanathan, Callon 179 [2] "A Framework for Multiprotocol Label Switching", 7/97, draft- 180 ietf-mpls-framework-01.txt, Callon, Doolan, Feldman, Fredette, 181 Swallow, Visanathawan 183 [3] "Tag Switching Architecture - Overview", 7/97, draft-rekhter- 184 tagswitch-arch-01.txt, Rekhter, Davie, Katz, Rosen, Swallow 186 [4] "MPLS Label Stack Encoding", 11/97, draft-ietf-mpls-label- 187 encaps-00.txt, Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, 188 Conta.