idnits 2.17.1 draft-zhang-ccamp-rsvpte-ber-measure-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3937 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) ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Z. Li 2 Internet-Draft L. Zhang 3 Intended status: Standards Track Huawei Technologies 4 Expires: January 16, 2014 July 15, 2013 6 RSVP-TE Extensions for Bit Error Rate (BER) Measurement 7 draft-zhang-ccamp-rsvpte-ber-measure-00 9 Abstract 11 In the mobile backhaul network, the mobile service is sensitive to 12 Bit Error Rate (BER). When the BER value of the service exceeds the 13 threshold, the Base Station will stop working and the User Equipments 14 (UEs) cannot obtain voice and data services anymore. Now the mobile 15 backhaul tends to be IP/MPLS network and MPLS TE LSP is used to bear 16 the mobile service which may be encapsulated in PW or L3VPN end to 17 end. Then the ingress Label Switched Router (LSR) of the MPLS TE LSP 18 needs to get information on BER along the path of the LSP. This 19 document proposes new extensions of RSVP-TE to advertise the BER 20 measurement requirement of the specific LSP to all of the transit 21 LSRs and the egress LSR, and to report the BER measurement result 22 from any transit or egress LSR towards the ingress LSR. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 16, 2014. 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. BER_REQUEST TLV . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Format of BER_REQUEST . . . . . . . . . . . . . . . . . . 3 68 3.2. Operations for BER_REQUEST TLV . . . . . . . . . . . . . 5 69 4. Bit Error Indication Report . . . . . . . . . . . . . . . . . 5 70 4.1. Error Code for BER measurement report . . . . . . . . . . 6 71 4.2. Operations for BER Error Code . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Bit Error Rate (BER) is a significant parameter for the mobile 80 service, which can cause the Base Station to stop working when its 81 value exceeds the threshold of the service. In IP/MPLS based mobile 82 backhaul network, PW and L3VPN are adopted to bear the mobile service 83 end-to-end, and MPLS TE LSP is adopted as the transport tunnel for 84 which Hot-standby (MPLS TE HSB) or fast reroute (MPLS TE FRR) 85 technologies is used to meet the SLA(Service Level Agreement). There 86 are different kinds of failure detection methods, such as BFD or MPLS 87 OAM, to trigger MPLS TE HSB or FRR to switch traffic fast when 88 failure happens. But as to BER, even if the BER value exceeds the 89 threshold, the detection mechanisms cannot detect the failure to 90 trigger traffic switch to the backup path. In this document, we 91 propose new extensions of RSVP-TE to advertise the BER measurement 92 requirement of the LSP to its transit LSRs and the egress LSR, and to 93 report the BER measurement result from any transit LSR or the egress 94 LSR towards the ingress LSR. 96 There are two types of BER measurement requirements: one is the 97 single-point BER measurement and the other is the multi-point BER 98 measurement. The first one is to measure if the BER value of one 99 point of the LSP path has exceeded the threshold of the service. The 100 second one is to measure if the sum of BER value of multiple points 101 of the LSP exceeds the threshold of the service. In this document, 102 we just focus on the single-point BER measurement . The multi-point 103 BER measurement will be described in the future version. 105 For the single-point BER measurement, there are two new extensions of 106 RSVP-TE protocol. One extension is to advertise the BER measurement 107 requirement to all of the transit LSRs and the egress LSR, then these 108 LSRs along the path will start BER measurement for the LSP. The 109 other extension is to report the BER measurement result from any 110 transit LSR or the egress LSR towards the ingress LSR. 112 2. Terminology 114 BER: Bit Error Rate 116 RAN: Radio Access Network 118 LSR: Label Switch Router 120 LSP: Label Switch Path 122 3. BER_REQUEST TLV 124 3.1. Format of BER_REQUEST 126 Path Message of RSVP-TE is used to signal the BER measurement 127 requirement of the LSP, and the LSP_ATTRIBUTES object will be 128 included in the Path Message. The LSP_ATTRIBUTES object which is 129 defined in [RFC5420] is used to signal attributes required in support 130 of an LSP, or to indicate the nature or use of an LSP. The 131 LSP_ATTRIBUTES object format is as below (refer to[RFC5420]): 133 LSP_ATTRIBUTES class = 197, C-Type = 1 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 // Attributes TLVs // 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 1: LSP_ATTRIBUTES object 145 The LSP_ATTRIBUTES object class is 197 of the form 11bbbbbb. This 146 C-Num value (see [RFC2205], Section 3.10) ensures that LSRs that do 147 not recognize the object pass it on transparently. One C-Type is 148 defined, C-Type = 1 for LSP Attributes. 150 The Attributes TLVs are encoded as below: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type | Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | | 158 // Value // 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 2: Attributes TLVs format 164 Here, we define the BER_REQUEST TLV, which is a new type of Attribute 165 TLV, to indicate the BER measurement requirement of the LSP. The 166 format of BER_REQUEST TLV is as below: 168 LSP_ATTRIBUTES Class=197, C-Type=1 169 Type=TBD,BER_REQ TLV 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type=BER_REQ TLV(TBD) | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | BER threshold | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 3:BER_REQ TLV 179 Type 181 The identifier of the BER_REQUEST TLV which should be allocated by 182 IANA. 184 Length 186 Indicates the total length of the TLV in two octets. 188 Value 190 The BER threshold of the service, which is a 32-bit IEEE floating 191 point number. Positive infinity is represented as an IEEE single- 192 precision floating-point number with an exponent of all ones (255) 193 and a sign and mantissa of all zeros. The format of IEEE floating- 194 point numbers is further summarized in [RFC1832] 196 3.2. Operations for BER_REQUEST TLV 198 BER_REQUEST TLV is one type of attribute TLVs of the LSP_ATTRIBUTE 199 object, which is optional and may be placed in Path messages to 200 advertise the BER measurement requirement of the LSP. The process of 201 the LSP_ATTRIBUTE object can refer to section 4.2 in [RFC5420]. 203 When a RSVP-TE LSP requires the BER measurement of the path, the 204 ingress LSR MUST send a Path Message with BER_REQUEST TLV in which 205 the BER threshold value is set. 207 When a LSR receives a Path Message with the BER_REQUEST TLV, the LSR 208 SHOULD start the BER measurement for the LSP. The LSR MUST pass the 209 Path Message with BER_REQUEST TLV unchanged to the next LSR. If the 210 measured BER value exceeds the BER threshold value set in the 211 BER_REQUEST TLV, the LSR MUST report the bit error result towards the 212 ingress LSR of the LSP. 214 If a LSR cannot support the BER_REQUEST TLV, the LSR SHOULD ignore 215 this TLV and pass the Path Message with BER_REQUEST TLV unchanged to 216 the next LSR. 218 For a LSR which has started the BER measurement on receiving the Path 219 Message with the BER_REQUEST UEST TLV, if the LSR receives the 220 updated Path Message without BER_REQUEST TLV, it MUST stop the BER 221 measurement for this LSP, and pass the Path Message to next LSRs 222 unchanged. 224 4. Bit Error Indication Report 225 For the single-point BER measurement, the LSR should report the BER 226 measurement result towards the ingress LSR of the LSP when the BER 227 measurement value exceeds the threshold of the service. This 228 document we propose a new type of Error Code and its Error Value of 229 the ERROR_SPEC object, which is defined in [RFC2205] and [RFC3209], 230 to report the BER measurement result within PathErr Message. 232 4.1. Error Code for BER measurement report 234 The ERROR_SPEC object is defined in [RFC2205] and [RFC3209]. Here we 235 define a new BER Error Code as below (The Error Code for "BER 236 measurement report" is to be defined) : 238 Error code Error value Description 239 ----------------------------------------------------------------- 240 TBD 0 Bit Error Elimination 241 1 Bit Error Indication 243 4.2. Operations for BER Error Code 245 The BER measurement result is reported through a new Error Code and 246 corresponding Error Value of the ERROR_SPEC object, which is placed 247 in PathErr Message. 249 For a LSR which has started the BER measurement for the specific LSP, 250 if the BER measurement value exceeds the threshold of the service, a 251 PathErr Message MUST be trigged to send towards the ingress LSR of 252 this LSP. The PathErr Message MUST include BER Error code with Error 253 Value 1 for Bit Error Indication. When the BER measurement value 254 becomes less than the BER threshold value, the LSR MUST send a 255 PathErr Message with a value of 0 for Bit Error Elimination. 257 5. IANA Considerations 259 IANA should allocate the type value of the BER_REQUEST TLV and the 260 BER Error Code, which are defined in this document. 262 6. Security Considerations 264 The extensions of RSVP TE for BER in this document do not introduce 265 any new security issues, and the reader is referred to the security 266 considerations expressed in [RFC2205], [RFC3209], and [RFC5420]. 268 7. Normative References 270 [RFC1832] Srinivasan, R., "XDR: External Data Representation 271 Standard", RFC 1832, August 1995. 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 277 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 278 Functional Specification", RFC 2205, September 1997. 280 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 281 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 282 Tunnels", RFC 3209, December 2001. 284 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 285 Ayyangarps, "Encoding of Attributes for MPLS LSP 286 Establishment Using Resource Reservation Protocol Traffic 287 Engineering (RSVP-TE)", RFC 5420, February 2009. 289 Authors' Addresses 291 Zhenbin Li 292 Huawei Technologies 293 Huawei Bld., No.156 Beiqing Rd. 294 Beijing 100095 295 China 297 Email: lizhenbin@huawei.com 299 Li Zhang 300 Huawei Technologies 301 Huawei Bld., No.156 Beiqing Rd. 302 Beijing 100095 303 China 305 Email: monica.zhangli@huawei.com