idnits 2.17.1 draft-ietf-ccamp-ospf-gmpls-extensions-00.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 81 == Unused Reference: 'OSPF-TE' is defined on line 244, 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 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-00 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group K. Kompella (Juniper Networks) 3 Internet Draft Y. Rekhter (Juniper Networks) 4 Expiration Date: March 2002 A. Banerjee (Calient Networks) 5 J. Drake (Calient Networks) 6 G. Bernstein (Ciena) 7 D. Fedyk (Nortel Networks) 8 E. Mannie (GTS Network) 9 D. Saha (Tellium) 10 V. Sharma (Metanoia, Inc.) 12 OSPF Extensions in Support of Generalized MPLS 14 draft-ietf-ccamp-ospf-gmpls-extensions-00.txt 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 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- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 2. Abstract 39 This document specifies encoding of extensions to the OSPF routing 40 protocol in support of Generalized Multi-Protocol Label Switching 41 (GMPLS). The description of the extensions is specified in [GMPLS- 42 ROUTING]. 44 3. Summary for Sub-IP Area 46 3.1. Summary 48 This document specifies encoding of extensions to the OSPF routing 49 protocol in support of Generalized Multi-Protocol Label Switching 50 (GMPLS). The description of the extensions is specified in [GMPLS- 51 ROUTING]. 53 3.2. Where does it fit in the Picture of the Sub-IP Work 55 This work fits squarely in either the CCAMP or OSPF box. 57 3.3. Why is it Targeted at this WG 59 This draft is targeted at the CCAMP or the OSPF WG, because this 60 draft specifies the extensions to the OSPF routing protocols in 61 support of GMPLS, because GMPLS is within the scope of the CCAMP WG, 62 and because OSPF is within the scope of the OSPF WG. 64 3.4. Justification 66 The WG should consider this document as it specifies the extensions 67 to the OSPF routing protocols in support of GMPLS. 69 4. Introduction 71 This document specifies extensions to the OSPF routing protocol in 72 support of carrying link state information for Generalized Multi- 73 Protocol Label Switching (GMPLS). The set of required enhancements to 74 OSPF are outlined in [GMPLS-ROUTING]. 76 5. OSPF Routing Enhancements 78 In this section we define the enhancements to the TE properties of 79 GMPLS TE links that can be announced in OSPF TE LSAs. The Traffic 80 Engineering (TE) LSA, which is an opaque LSA with area flooding scope 81 [3], has only one top-level Type/Length/Value (TLV) triplet and has 82 one or more nested TLVs for extensibility. The top-level TLV can 83 take one of two values (1) Router Address or (2) Link. In this 84 document, we enhance the sub-TLVs for the Link TLV in support of 85 GMPLS. Specifically, we add the following sub-TLVs: 87 1. Outgoing Interface Identifier, 88 2. Incoming Interface Identifier, 89 3. Interface MTU 90 4. Link Protection Type, 91 5. Shared Risk Link Group, and 92 6. Interface Switching Capability Descriptor. 94 This brings the list of sub-TLVs of the TE Link TLV to: 96 Sub-TLV Type Length Name 97 1 1 Link type 98 2 4 Link ID 99 3 4 Local interface IP address 100 4 4 Remote interface IP address 101 5 4 Traffic engineering metric 102 6 4 Maximum bandwidth 103 7 4 Maximum reservable bandwidth 104 8 32 Unreserved bandwidth 105 9 4 Resource class/color 106 10 2 Interface MTU 107 11 4 Outgoing Interface Identifier 108 12 4 Incoming Interface Identifier 109 14 4 Link Protection Type 110 16 variable Shared Risk Link Group 111 15 variable Interface Switching Capability Descriptor 112 32768-32772 - Reserved for Cisco-specific extensions 113 5.1. Interface MTU 115 The Interface MTU is a sub-TLV of the Link TLV with type 10, length 116 2, and value equal to the maximum size of an IP packet that can be 117 transmitted on this interface without being fragmented. 119 5.2. Outgoing Interface Identifier 121 An Outgoing Interface Identifier is a sub-TLV of the Link TLV with 122 type 11, length 4, and value equal to the assigned identifier. 124 5.3. Incoming Interface Identifier 126 An Incoming Interface Identifier is a sub-TLV of the Link TLV with 127 type 12, length 4, and value equal to the assigned identifier. 129 5.4. Link Protection Type 131 The Link Protection Type is a sub-TLV of the Link TLV, with type 14, 132 and length of four octets, the first of which is a bit vector 133 describing the protection capabilities of the link. They are: 135 0x01 Extra Traffic 137 0x02 Unprotected 139 0x04 Shared 141 0x08 Dedicated 1:1 143 0x10 Dedicated 1+1 145 0x20 Enhanced 147 0x40 Reserved 149 0x80 Reserved 151 5.5. Shared Risk Link Group (SRLG) 153 The SRLG is a sub-TLV of the Link TLV with type 16. The length is the 154 length of the list in octets. The value is an unordered list of 32 155 bit numbers that are the SRLGs that the link belongs to. The format 156 is as shown below: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | 16 | 4 * No. of SRLGs in link | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Shared Risk Link Group Value | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | ............ | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Shared Risk Link Group Value | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 5.6. Interface Switching Capability Descriptor 172 The Interface Switching Capability Descriptor is a sub-TLV of the 173 Link TLV with type 15. The length is the length of value field in 174 octets. The format of the value field is as shown below: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Switching Cap | Encoding | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Max LSP Bandwidth at priority 0 | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Max LSP Bandwidth at priority 1 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Max LSP Bandwidth at priority 2 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Max LSP Bandwidth at priority 3 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Max LSP Bandwidth at priority 4 | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Max LSP Bandwidth at priority 5 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Max LSP Bandwidth at priority 6 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Max LSP Bandwidth at priority 7 | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Switching Capability-specific information | 198 | (variable) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 The Switching Capability (Switching Cap) field contains one of the 201 following values: 203 1 Packet-Switch Capable-1 (PSC-1) 204 2 Packet-Switch Capable-2 (PSC-2) 205 3 Packet-Switch Capable-3 (PSC-3) 206 4 Packet-Switch Capable-4 (PSC-4) 207 51 Layer-2 Switch Capable (L2SC) 208 100 Time-Division-Multiplex Capable (TDM) 209 150 Lambda-Switch Capable (LSC) 210 200 Fiber-Switch Capable (FSC) 212 The Encoding field contains one of the values specified in Section 213 3.1.1 of [GMPLS-SIG]. 215 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 216 the IEEE floating point format, with priority 0 first and priority 7 217 last. 219 The content of the Switching Capability specific information field 220 depends on the value of the Switching Capability field. 222 When the Switching Capability field is PSC-1, PSC-2, PSC-3, PSC-4, or 223 L2SC, there is no specific information. 225 When the Switching Capability field is TDM, the specific information 226 includes Minimum LSP Bandwidth, which is is encoded in a 4 octets 227 field in the IEEE floating point format. 229 When the Switching Capability field is LSC, there is no specific 230 information. 232 6. Security Considerations 234 The sub-TLVs proposed in this document does not raise any new 235 security concerns. 237 7. Acknowledgements 239 The authors would like to thank Suresh Katukam, Jonathan Lang and 240 Quaizar Vohra for their comments on the draft. 242 8. References 244 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 245 OSPF", 246 draft-katz-yeung-ospf-traffic-04.txt (work in progress) 248 [GMPLS-SIG] "Generalized MPLS - Signaling Functional 249 Description", draft-ietf-mpls-generalized-signaling-04.txt (work 250 in progress) 252 [GMPLS-ROUTING] "Routing Extensions in Support of Generalized MPLS", 253 draft-ietf-ccamp-gmpls-routing-00.txt 255 9. Authors' Information 257 Kireeti Kompella 258 Juniper Networks, Inc. 259 1194 N. Mathilda Ave 260 Sunnyvale, CA 94089 261 Email: kireeti@juniper.net 263 Yakov Rekhter 264 Juniper Networks, Inc. 265 1194 N. Mathilda Ave 266 Sunnyvale, CA 94089 267 Email: yakov@juniper.net 269 Ayan Banerjee 270 Calient Networks 271 5853 Rue Ferrari 272 San Jose, CA 95138 273 Phone: +1.408.972.3645 274 Email: abanerjee@calient.net 275 John Drake 276 Calient Networks 277 5853 Rue Ferrari 278 San Jose, CA 95138 279 Phone: (408) 972-3720 280 Email: jdrake@calient.net 282 Greg Bernstein 283 Ciena Corporation 284 10480 Ridgeview Court 285 Cupertino, CA 94014 286 Phone: (408) 366-4713 287 Email: greg@ciena.com 289 Don Fedyk 290 Nortel Networks Corp. 291 600 Technology Park Drive 292 Billerica, MA 01821 293 Phone: +1-978-288-4506 294 Email: dwfedyk@nortelnetworks.com 296 Eric Mannie 297 GTS Network Services 298 RDI Department, Core Network Technology Group 299 Terhulpsesteenweg, 6A 300 1560 Hoeilaart, Belgium 301 Phone: +32-2-658.56.52 302 E-mail: eric.mannie@gtsgroup.com 304 Debanjan Saha 305 Tellium Optical Systems 306 2 Crescent Place 307 P.O. Box 901 308 Ocean Port, NJ 07757 309 Phone: (732) 923-4264 310 Email: dsaha@tellium.com 311 Vishal Sharma 312 Metanoia, Inc. 313 335 Elan Village Lane, Unit 203 314 San Jose, CA 95134-2539 315 Phone: +1 408-943-1794 316 Email: v.sharma@ieee.org