idnits 2.17.1 draft-kompella-ospf-gmpls-extensions-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([GMPLS-ROUTING]), 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.) -- 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) -- Looks like a reference, but probably isn't: '3' on line 80 == Unused Reference: 'OSPF-TE' is defined on line 236, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-04 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ROUTING' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella (Juniper Networks) 2 Internet Draft Y. Rekhter (Juniper Networks) 3 Expiration Date: January 2002 A. Banerjee (Calient Networks) 4 J. Drake (Calient Networks) 5 G. Bernstein (Ciena) 6 D. Fedyk (Nortel Networks) 7 E. Mannie (GTS Network) 8 D. Saha (Tellium) 9 V. Sharma (Tellabs) 11 OSPF Extensions in Support of Generalized MPLS 13 draft-kompella-ospf-gmpls-extensions-02.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 2. Abstract 38 This document specifies encoding of extensions to the OSPF routing 39 protocol in support of Generalized Multi-Protocol Label Switching 40 (GMPLS). The description of the extensions is specified in [GMPLS- 41 ROUTING]. 43 3. Summary for Sub-IP Area 45 3.1. Summary 47 This document specifies encoding of extensions to the OSPF routing 48 protocol in support of Generalized Multi-Protocol Label Switching 49 (GMPLS). The description of the extensions is specified in [GMPLS- 50 ROUTING]. 52 3.2. Where does it fit in the Picture of the Sub-IP Work 54 This work fits squarely in either the CCAMP or OSPF box. 56 3.3. Why is it Targeted at this WG 58 This draft is targeted at the CCAMP or the OSPF WG, because this 59 draft specifies the extensions to the OSPF routing protocols in 60 support of GMPLS, because GMPLS is within the scope of the CCAMP WG, 61 and because OSPF is within the scope of the OSPF WG. 63 3.4. Justification 65 The WG should consider this document as it specifies the extensions 66 to the OSPF routing protocols in support of GMPLS. 68 4. Introduction 70 This document specifies extensions to the OSPF routing protocol in 71 support of carrying link state information for Generalized Multi- 72 Protocol Label Switching (GMPLS). The set of required enhancements to 73 OSPF are outlined in [GMPLS-ROUTING]. 75 5. OSPF Routing Enhancements 77 In this section we define the enhancements to the TE properties of 78 GMPLS TE links that can be announced in OSPF TE LSAs. The Traffic 79 Engineering (TE) LSA, which is an opaque LSA with area flooding scope 80 [3], has only one top-level Type/Length/Value (TLV) triplet and has 81 one or more nested TLVs for extensibility. The top-level TLV can 82 take one of two values (1) Router Address or (2) Link. In this 83 document, we enhance the sub-TLVs for the Link TLV in support of 84 GMPLS. Specifically, we add the following sub-TLVs: 86 1. Outgoing Interface Identifier, 87 2. Incoming Interface Identifier, 88 3. Link Protection Type, 89 4. Shared Risk Link Group, and 90 5. Interface Switching Capability Descriptor. 92 This brings the list of sub-TLVs of the TE Link TLV to: 94 Sub-TLV Type Length Name 95 1 1 Link type 96 2 4 Link ID 97 3 4 Local interface IP address 98 4 4 Remote interface IP address 99 5 4 Traffic engineering metric 100 6 4 Maximum bandwidth 101 7 4 Maximum reservable bandwidth 102 8 32 Unreserved bandwidth 103 9 4 Resource class/color 104 11 4 Outgoing Interface Identifier 105 12 4 Incoming Interface Identifier 106 14 4 Link Protection Type 107 16 variable Shared Risk Link Group 108 15 variable Interface Switching Capability Descriptor 109 32768-32772 - Reserved for Cisco-specific extensions 110 5.1. Outgoing Interface Identifier 112 An Outgoing Interface Identifier is a sub-TLV of the Link TLV with 113 type 11, length 4, and value equal to the assigned identifier. 115 5.2. Incoming Interface Identifier 117 An Incoming Interface Identifier is a sub-TLV of the Link TLV with 118 type 12, length 4, and value equal to the assigned identifier. 120 5.3. Link Protection Type 122 The Link Protection Type is a sub-TLV of the Link TLV, with type 14, 123 and length of four octets, the first of which is a bit vector 124 describing the protection capabilities of the link. They are: 126 0x01 Extra Traffic 128 0x02 Unprotected 130 0x04 Shared 132 0x08 Dedicated 1:1 134 0x10 Dedicated 1+1 136 0x20 Enhanced 138 0x40 Reserved 140 0x80 Reserved 142 5.4. Shared Risk Link Group (SRLG) 144 The SRLG is a sub-TLV of the Link TLV with type 16. The length is the 145 length of the list in octets. The value is an unordered list of 32 146 bit numbers that are the SRLGs that the link belongs to. The format 147 is as shown below: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | 16 | 4 * No. of SRLGs in link | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Shared Risk Link Group Value | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | ............ | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Shared Risk Link Group Value | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 5.5. Interface Switching Capability Descriptor 163 The Interface Switching Capability Descriptor is a sub-TLV of the 164 Link TLV with type 15. The length is the length of value field in 165 octets. The format of the value field is as shown below: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Switching Cap | Encoding | Reserved | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Max LSP Bandwidth at priority 0 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Max LSP Bandwidth at priority 1 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Max LSP Bandwidth at priority 2 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Max LSP Bandwidth at priority 3 | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Max LSP Bandwidth at priority 4 | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Max LSP Bandwidth at priority 5 | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Max LSP Bandwidth at priority 6 | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Max LSP Bandwidth at priority 7 | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Switching Capability-specific information | 189 | (variable) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 The Switching Capability (Switching Cap) field contains one of the 193 following values: 195 1 Packet-Switch Capable-1 (PSC-1) 196 2 Packet-Switch Capable-2 (PSC-2) 197 3 Packet-Switch Capable-3 (PSC-3) 198 4 Packet-Switch Capable-4 (PSC-4) 199 51 Layer-2 Switch Capable (L2SC) 200 100 Time-Division-Multiplex Capable (TDM) 201 150 Lambda-Switch Capable (LSC) 202 200 Fiber-Switch Capable (FSC) 204 The Encoding field contains one of the values specified in Section 205 3.1.1 of [GMPLS-SIG]. 207 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 208 the IEEE floating point format, with priority 0 first and priority 7 209 last. 211 The content of the Switching Capability specific information field 212 depends on the value of the Switching Capability field. 214 When the Switching Capability field is PSC-1, PSC-2, PSC-3, PSC-4, or 215 L2SC, there is no specific information. 217 When the Switching Capability field is TDM, the specific information 218 includes Minimum LSP Bandwidth, which is is encoded in a 4 octets 219 field in the IEEE floating point format. 221 When the Switching Capability field is LSC, there is no specific 222 information. 224 6. Security Considerations 226 The sub-TLVs proposed in this document does not raise any new 227 security concerns. 229 7. Acknowledgements 231 The authors would like to thank Suresh Katukam, Jonathan Lang and 232 Quaizar Vohra for their comments on the draft. 234 8. References 236 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 237 OSPF", 238 draft-katz-yeung-ospf-traffic-04.txt (work in progress) 240 [GMPLS-SIG] "Generalized MPLS - Signaling Functional 241 Description", draft-ietf-mpls-generalized-signaling-04.txt (work 242 in progress) 244 [GMPLS-ROUTING] "Routing Extensions in Support of Generalized MPLS", 245 draft-many-ccamp-gmpls-routing-00.txt 247 9. Authors' Information 249 Kireeti Kompella 250 Juniper Networks, Inc. 251 1194 N. Mathilda Ave 252 Sunnyvale, CA 94089 253 Email: kireeti@juniper.net 255 Yakov Rekhter 256 Juniper Networks, Inc. 257 1194 N. Mathilda Ave 258 Sunnyvale, CA 94089 259 Email: yakov@juniper.net 261 Ayan Banerjee 262 Calient Networks 263 5853 Rue Ferrari 264 San Jose, CA 95138 265 Phone: +1.408.972.3645 266 Email: abanerjee@calient.net 267 John Drake 268 Calient Networks 269 5853 Rue Ferrari 270 San Jose, CA 95138 271 Phone: (408) 972-3720 272 Email: jdrake@calient.net 274 Greg Bernstein 275 Ciena Corporation 276 10480 Ridgeview Court 277 Cupertino, CA 94014 278 Phone: (408) 366-4713 279 Email: greg@ciena.com 281 Don Fedyk 282 Nortel Networks Corp. 283 600 Technology Park Drive 284 Billerica, MA 01821 285 Phone: +1-978-288-4506 286 Email: dwfedyk@nortelnetworks.com 288 Eric Mannie 289 GTS Network Services 290 RDI Department, Core Network Technology Group 291 Terhulpsesteenweg, 6A 292 1560 Hoeilaart, Belgium 293 Phone: +32-2-658.56.52 294 E-mail: eric.mannie@gtsgroup.com 296 Debanjan Saha 297 Tellium Optical Systems 298 2 Crescent Place 299 P.O. Box 901 300 Ocean Port, NJ 07757 301 Phone: (732) 923-4264 302 Email: dsaha@tellium.com 303 Vishal Sharma 304 Jasmine Networks, Inc. 305 3061 Zanker Rd, Suite B 306 San Jose, CA 95134 307 Phone: (408) 895-5000