idnits 2.17.1 draft-ietf-pwe3-status-reduction-02.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 (October 2013) is 3846 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 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-static-pw-status-06 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft George Swallow 4 Intended status: Standards Track Cisco 5 Expires: April 2014 6 Elisa Bellagamba 7 Ericsson 9 October 2013 11 MPLS LSP PW status refresh reduction for Static Pseudowires 13 draft-ietf-pwe3-status-reduction-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 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 This Internet-Draft will expire on April 20, 2010 38 Abstract 40 This document describes a method for generating an aggregated 41 pseudowire status message on Multi-Protocol Label Switching (MPLS) 42 network Label Switched Path (LSP). 44 The method for transmitting the pseudowire (PW) status information is 45 not new, however this protocol extension allows a Service Provider 46 (SP) to reliably monitor the individual PW status while not 47 overwhelming the network of multiple periodic status messages. This 48 is achieved by sending a single cumulative summary status 49 verification message for all the PWs grouped in the same LSP. 51 Table of Contents 53 1 Introduction ......................................... 3 54 1.1 Requirements Language ................................ 3 55 1.2 Terminology .......................................... 3 56 1.3 Notational Conventions in Backus-Naur Form ........... 4 57 2 PW status refresh reduction protocol ................. 4 58 2.1 Protocol states ...................................... 4 59 2.1.1 INACTIVE ............................................. 5 60 2.1.2 STARTUP .............................................. 5 61 2.1.3 ACTIVE ............................................... 5 62 2.2 Timer value change transition procedure .............. 5 63 3 PW status refresh reduction procedure ................ 6 64 4 PW status refresh reduction Message Encoding ......... 6 65 5 PW status refresh reduction Control Messages ......... 9 66 5.0.1 Notification message ................................. 10 67 5.0.2 PW Configuration Message ............................. 10 68 5.0.2.1 MPLS-TP Tunnel ID .................................... 11 69 5.0.2.2 PW ID configured List ................................ 11 70 5.0.2.3 PW ID unconfigured List .............................. 12 71 6 PW provisioning verification procedure ............... 13 72 6.1 PW ID List advertising and processing ................ 13 73 7 Security Considerations .............................. 14 74 8 IANA Considerations .................................. 14 75 8.1 PW Status Refresh Reduction Message Types ............ 14 76 8.2 PW Configuration Message Sub-TLVs .................... 14 77 8.3 PW Status Refresh Reduction Notification Codes ....... 15 78 9 References ........................................... 15 79 9.1 Normative References ................................. 15 80 9.2 Informative References ............................... 16 81 10 Author's Addresses ................................... 16 83 1. Introduction 85 When PWs use a Multi Protocol Label Switched (MPLS) network as the 86 Packet Switched Network (PSN), they are setup according to [RFC4447] 87 static configuration mode and the PW status information is propagated 88 using the method described in [PW-STATUS]. There are 2 basic modes of 89 operation described in [PW-STATUS] section 5.3: Periodic 90 retransmission of non-zero status messages, and a simple acknowledge 91 of PW status (sec 5.3.1 of [PW-STATUS]). The LSP level protocol 92 described below applies to the case when PW status is acknowledged 93 immediately with a requested refresh value of zero (no refresh). In 94 this case the PW status refresh reduction protocol is necessary for 95 several reasons, such as: 97 -i. Greatly increase the scalability of the PW status protocol 98 by reducing the amount of messages that a PE needs to 99 periodically send to it's neighbors. 100 -ii. Detect a remote PE restart. 101 -iii. If the local state is lost for some reason, the PE needs to 102 be able to request a status refresh reduction from the 103 remote PE 104 -iv. Optionally detect a remote PE provisioning change. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 1.2. Terminology 114 FEC: Forwarding Equivalence Class 116 LDP: Label Distribution Protocol 118 LSP: Label Switching Path 120 MS-PW: Multi-Segment Pseudowire 122 PE: Provider Edge 124 PW: Pseudowire 126 SS-PW: Single-Segment Pseudowire 128 S-PE: Switching Provider Edge Node of MS-PW 129 T-PE: Terminating Provider Edge Node of MS-PW 131 1.3. Notational Conventions in Backus-Naur Form 133 All multiple-word atomic identifiers use underscores (_) between the 134 words to join the words. Many of the identifiers are composed of a 135 concatenation of other identifiers. These are expressed using 136 Backus-Naur Form (using double-colon - "::" - notation). 138 Where the same identifier type is used multiple times in a 139 concatenation, they are qualified by a prefix joined to the 140 identifier by a dash (-). For example Src-Node_ID is the Node_ID of 141 a node referred to as Src (where "Src" is short for "source" in this 142 example). 144 The notation does not define an implicit ordering of the information 145 elements involved in a concatenated identifier. 147 2. PW status refresh reduction protocol 149 PW status refresh reduction protocol consists of a simple message 150 that is sent at the LSP level using the MPLS Generic Associated 151 Channel. 153 A PE using the PW status refresh reduction protocol MUST send the PW 154 status refresh reduction Message as soon as a PW is configured on a 155 particular LSP. The message is then re-transmitted at a locally 156 configured interval indicated in the refresh timer field. If no 157 acknowledgment is received, the protocol does not reach active state, 158 and the PE SHOULD NOT send any PW status messages with a refresh 159 timer of zero as described in [PW-STATUS] section 5.3.1. 161 It is worth noting that no relationship is existing between the 162 locally configured timer for the refresh reduction protocol and the 163 PW individual status refresh timers. 165 2.1. Protocol states 167 The protocol can be in 3 possible states: INACTIVE, STARTUP, and 168 ACTIVE. 170 2.1.1. INACTIVE 172 This state is entered when the protocol is turned off. This state is 173 also entered if all PW on a specific LSP are unprovisioned, or the 174 feature is unprovisioned. 176 2.1.2. STARTUP 178 In this state the PE transmits periodic PW status refresh reduction 179 messages, with the Ack Session ID set to 0. The PE remains in this 180 state until a PW status refresh message is received with the correct 181 local session ID in the Ack Session ID Field. This state can be 182 exited to the ACTIVE or INACTIVE state. 184 2.1.3. ACTIVE 186 This state is entered once the PE receives a PW status refresh 187 reduction message with the correct local session ID in the Ack 188 Session ID Field within 3.5 times the refresh timer field value of 189 the last PW status refresh reduction message transmitted. This state 190 is immediately exited as follows: 192 -i. A valid PW status refresh reduction message is not received 193 within 3.5 times the current refresh timer field value. 194 (assuming a timer transition procedure is not in progress) 195 New state: STARTUP 196 -ii. A PW status refresh reduction message is received with the 197 wrong, or a zero, Ack Session ID field value. New state: 198 STARTUP 199 -iii. All PWs using the particular LSP are unprovisioned, or the 200 protocol is disabled. New state: INACTIVE 202 2.2. Timer value change transition procedure 204 If a PE needs to change the refresh timer value field while the PW 205 refresh reduction protocol is in the ACTIVE state, the following 206 procedure must be followed: 207 -i. A PW status refresh reduction message is transmitted with 208 the new timer value. 209 -ii. If the new value is greater then the original one the PE 210 will operate on the new timer value immediately. 211 -iii. If the new value is smaller then the original one, the PE 212 will operate according to the original timer value for a 213 period 3.5 times the original timer value, or until the 214 first valid PW status refresh reduction message is received. 216 A PE receiving a PW status refresh reduction message with a 217 new timer value, will immediately transmit an acknowledge PW 218 status refresh reduction message, and start operating 219 according to the new timer value. 221 3. PW status refresh reduction procedure 223 When the refresh reduction protocol, on a particular LSP, is in the 224 ACTIVE state, the PE can send all PW status messages, for PWs on that 225 LSP, with a refresh timer value of zero. This greatly decreases the 226 amount of messages that the PE needs to transmit to the remote PE 227 because once the PW status message for a particular PW is 228 acknowledged, further repetitions of that message are no longer 229 necessary. 231 To further mitigate the amount of possible messages when an LSP 232 starts forwarding traffic, care should be taken to permit the PW 233 refresh reduction protocol to reach the ACTIVE state quickly, and 234 before the the first PW status refresh timer expires. This can be 235 achieved by using a PW status refresh reduction Message refresh timer 236 value that is much smaller then the PW status message refresh timer 237 value in use. (sec 5.3.1 of [PW-STATUS]) 239 If the refresh reduction protocol session is terminated by entering 240 the INACTIVE or STARTUP states, the PE MUST immediately re-send all 241 the previously sent PW status messages for that particular LSP for 242 which the session terminated. In this case the refresh timer value 243 MUST NOT be set to zero, and MUST be set according to the local 244 policy of the PE router. 246 4. PW status refresh reduction Message Encoding 248 The packet containing the refresh reduction message is encoded as 249 follows: (omitting link layer information) 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | MPLS LSP (tunnel) Label | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | GAL | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Session ID | Ack Session ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Refresh Timer | Total Message Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Checksum | Message Sequence Number | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Last Received Seq Number | Message Type |U C Flags | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 ~ Control Message Body ~ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 This message contains the following fields: 274 * PW OAM Message. 276 This field indicates the generic associated channel type in the 277 GACH header as defined in [RFC5586]. 279 Note: Channel type 0xZZ pending IANA allocation. 281 * Session ID 283 A non-zero, locally selected session number that is not preserved 284 if the local PE restarts. 286 In order to get a locally unique session ID, the recommended 287 choice is to perform a CRC-16 giving as input the following data 289 |Y|Y|M|M|D|D|H|H|M|M|S|S|L|L|L| 291 Where: YY: are the decimal two last digit of the current year 292 MM: are the decimal two digit of the current month DD: are the 293 decimal two digit of the current day HHMMSSLLL: are the decimal 294 digits of the current time expressed in (hour, minutes, seconds, 295 milliseconds) 297 * Ack Session ID 299 The Acknowledgment Session ID received from the remote PE. 301 * Refresh Timer. 303 A non zero unsigned 16 bit integer value greater or equal to 10, 304 in milliseconds, that indicates the desired refresh interval. The 305 default value of 30000 is RECOMENDED. 307 * Total Message Length 309 Total length in octets of the Checksum, Message Type, Flags, 310 Message Sequence Number, and control message body. A value of 311 zero means that no control message is present, and therefore that 312 no Checksum, and following fields are present either. 314 * Checksum 316 A 16 bit field containing the one's complement of the one's 317 complement sum of the entire message (including the GACH header), 318 with the checksum field replaced by zero for the purpose of 319 computing the checksum. An all-zero value means that no checksum 320 was transmitted. Note that when the checksum is not computed, the 321 header of the bundle message will not be covered by any checksum. 323 * Message Sequence Number 325 A unsigned 16 bit integer number that is started from 1 when the 326 protocol enters ACTIVE state. The sequence numbers wraps back to 327 1 when the maximum value is reached. The value of zero is 328 reserved and MUST NOT be used. 330 * Last Received Message Sequence Number 332 The sequence number of the last message received. In no message 333 has yet been received during this session, this field is set to 334 zero. 336 * Message Type 338 The Type of the control message that follows. Control message 339 types are allocated in this document, and by IANA. 341 * (U) Unknown flag bit. 343 Upon receipt of an unknown message, if U is clear (=0), the 344 keepalive session MUST be terminated by entering STARTUP state; 345 if U is set (=1), the unknown message MUST be acknowledge and 346 silently ignored and the following messages, if any, processed as 347 if the unknown message did not exist. 349 * (C) Configuration flag bit. The C Bit is used to signal the end 350 of PW configuration transmission. If it is set, the sending PE 351 has finished sending all it's current configuration information. 353 * Flags (Reserved) 355 7 bits of flags reserved for future use, they MUST be set to 0 on 356 transmission, and ignored on reception. 358 * Control Message Body 360 The Control Message body is defined in a section below, and is 361 specific to the type of message. 363 It should be noted that the Checksum, Message Sequence Number, Last 364 Received Message Sequence Number, Message Type, Flags, and control 365 message body are OPTIONAL. 367 5. PW status refresh reduction Control Messages 369 PW status refresh reduction Control messages consist of the Checksum, 370 Message Sequence Number, Last Received Message Sequence Number, 371 Message Type, Flags, and control message body. 373 When there is the need to send a PW status refresh reduction Control 374 Messages, the system can attach it to a scheduled PW status refresh 375 reduction or send one ahead of time. In any case PW status refresh 376 reduction Control Messages always piggy back on normal messages. 378 There can only be one control message construct per PW status refresh 379 reduction Message. If the U bit is set, and a PE receiving the PW 380 status refresh reduction Message does not understand the control 381 message, the control message MUST be silently ignored. However the 382 control message sequence number MUST still be acknowledged by sending 383 a null message back with the appropriate value in the Last Message 384 Received Field. If a control message is not acknowledged, after 3.5 385 times the value of the Refresh Timer, a fatal notification 386 "unacknowledged control message" MUST be sent, and the PW refresh 387 reduction session MUST be terminated. 389 If a PE does not want or need to send a control message, the 390 Checksum, and all following fields MUST NOT be sent, and the Total 391 Message Length field is then set to zero. 393 5.0.1. Notification message 395 The most common use of the Notification Message is to acknowledge the 396 reception of a message by indicating the received message sequence 397 number in the "Last Received Sequence Number" field. The notification 398 message is encoded as follows: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Checksum | Message Sequence Number | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Last Received Seq Number | Type=0x01 |U Flags | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Notification Code | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 The message type is set to 0x01, and the U bit is treated as 411 described in the above section. The Notification Codes are a 32 bit 412 quantity assigned by IANA. (see IANA consideration section) 413 Notification codes are either considered "Error codes" or simple 414 notifications. If the Notification code is an Error code as indicated 415 in the IANA allocation registry, the keepalive session MUST be 416 terminated by entering STARTUP state. 418 5.0.2. PW Configuration Message 420 The PW status refresh reduction TLVs are informational TLVs, that 421 allow the remote PE to verify certain provisioning information. This 422 message contain a series of sub-TLVs in no particular order, that 423 contain PW and LSP configuration information. The message has no 424 preset length limit, however its total length will be limited by the 425 transport network Maximum Transmit Unit (MTU). 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Checksum | Message Sequence Number | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Last Received Seq Number | Type=0x02 |U C (Flags) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ~ ~ 435 | PW Configuration Message Sub-TLVs | 436 ~ ~ 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 The PW Configuration Message type is set to 0x02. For this message 439 the U-bit is set to 1 as processing of these messages is OPTIONAL. 441 The C Bit is used to signal the end of PW configuration transmission. 442 If it is set, the sending PE has finished sending all its current 443 configuration information. The PE transmitting the configuration MUST 444 set the C bit on the last PW configuration message when all current 445 PW configuration has been sent. 447 5.0.2.1. MPLS-TP Tunnel ID 449 This TLV contains the address of the MPLS-TP tunnel ID. When the 450 configuration message is used for a particular keepalive session the 451 MPLS-TP Tunnel ID sub-TLV MUST be sent at least once. 453 The MPLS-TP Tunnel ID address is encoded as follows: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type=0x01 | Length=20 | MPLS-TP Tunnel ID address | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 ~ ~ 461 | MPLS-TP Tunnel ID address (20 Octets) | 462 ~ ~ 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 The MPLS-TP point to point tunnel ID is defined in [IDENTIFIER] as 466 follows: 468 Src-Global_Node_ID::Src-Tunnel_Num::Dst-Global_Node_ID::Dst- 469 Tunnel_Num 471 Note that a single address is enough to identify the tunnel, and the 472 source end of the message. 474 5.0.2.2. PW ID configured List 476 This OPTIONAL TLV contains a list of the provisioned PWs on the LSP. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type=0x02 | Length | PW Path ID | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 | PW Path ID | 485 ~ ~ 486 | Continued | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 The PW Path ID is a 32 octet pseudowire path identifier specified in 490 [IDENTIFIER] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: 491 Dst-Global_ID::Dst-Node_ID::Dst-AC_ID 493 The number of PW Path IDs in the TLV will be inferred by the length 494 of the TLV up to a maximum of 8. The procedure for processing this 495 TLV will be described in a section below. 497 5.0.2.3. PW ID unconfigured List 499 This OPTIONAL TLV contains a list of the PWs that have been 500 unprovisioned on the LSP. Note that it is a fatal session error to 501 send the same PW address in both the configured list TLV , and the 502 unconfigured list TLV in the same configuration message. 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type=0x03 | Length | PW Path ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | | 510 | PW Path ID | 511 ~ ~ 512 | Continued | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 The PW Path ID is a 32 octet pseudowire path identifier specified in 516 [IDENTIFIER] as follows: AGI::Src-Global_ID::Src-Node_ID::Src-AC_ID:: 517 Dst-Global_ID::Dst-Node_ID::Dst-AC_ID 519 The number of PW Path IDs in the TLV will be inferred by the length 520 of the TLV up to a maximum of 8. 522 6. PW provisioning verification procedure 524 This procedure and the advertisement of the PW configuration message 525 are OPTIONAL. 527 A PE that desires to use the PW configuration message to verify the 528 configuration of PWs on a particular LSP, should advertise its PW 529 configuration to the remote PE on LSPs that have active keepalive 530 sessions. When a PE receives PW configuration information using this 531 protocol and it not supporting or not willing to use the information, 532 it MUST acknowledge all the PW configuration messages with a 533 notification of "PW configuration not supported". In this case, the 534 information in the control messages is silently ignored. If a PE 535 receives such a notification it should stop sending PW configuration 536 control messages for the duration of the PW refresh reduction 537 keepalive session. 539 If PW configuration information is received, it is used to verify the 540 accuracy of the local configuration information against the remote 541 PE's configuration information. If a configuration mismatch is 542 detected, where a particular PW is configured locally but not on the 543 remote PE, the following action SHOULD be taken: 545 -i. The local PW MUST be considered in "Not Forwarding" State. 547 -ii. The PW Attachment Circuit status is set to reflect the PW 548 fault. 550 -iii. An Alarm MAY be raised to a network management system. 552 6.1. PW ID List advertising and processing 554 When configuration messages are advertised along a particular LSP, 555 the PE sending the messages needs to check point the configuration 556 information sent by setting the C bit when all currently known 557 configuration information has been sent. This process allows the 558 receiving PE to immediately proceed to verify all the currently 559 configured PWs on that LSP, eliminating the need for a long waiting 560 period. 562 If a new PW is added to a particular LSP, the PE MUST place the 563 configuration verification of this PW on hold for a period of at 564 least 10 seconds. This is necessary to prevent false positive events 565 of mis-configuration due to the ends of the PW being slightly out of 566 sync. 568 7. Security Considerations 570 Section to be completed in a later version of the document. 572 8. IANA Considerations 574 8.1. PW Status Refresh Reduction Message Types 576 IANA needs to set up a registry of "PW status refresh reduction 577 Control Messages". These are 8-bit values. Type value 1 through 2 are 578 defined in this document. Type values 3 through 64 are to be assigned 579 by IANA using the "Expert Review" policy defined in RFC5226. Type 580 values 65 through 127, 0 and 255 are to be allocated using the IETF 581 consensus policy defined in [RFC5226]. Type values 128 through 254 582 are reserved for vendor proprietary extensions and are to be assigned 583 by IANA, using the "First Come First Served" policy defined in 584 RFC5226. 586 The Type Values are assigned as follows: 587 Type Message Description 588 ---- ------------------- 589 0x01 Notification message 590 0x02 PW Configuration Message 592 8.2. PW Configuration Message Sub-TLVs 594 IANA needs to set up a registry of "PW status refresh reduction 595 Configuration Message Sub-TLVs". These are 8-bit values. Type value 1 596 through 2 are defined in this document. Type values 3 through 64 are 597 to be assigned by IANA using the "Expert Review" policy defined in 598 RFC5226. Type values 65 through 127, 0 and 255 are to be allocated 599 using the IETF consensus policy defined in [RFC5226]. Type values 128 600 through 254 are reserved for vendor proprietary extensions and are to 601 be assigned by IANA, using the "First Come First Served" policy 602 defined in RFC5226. 604 The Type Values are assigned as follows: 605 sub-TLV type Description 606 ------------ ----------- 607 0x01 MPLS-TP Tunnel ID address. 608 0x02 PW ID configured List. 609 0x03 PW ID unconfigured List. 611 8.3. PW Status Refresh Reduction Notification Codes 613 IANA needs to set up a registry of "PW status refresh reduction 614 Notification Codes". These are 32-bit values. Type value 1 through 7 615 are defined in this document. Type values 8 through 65536 are to be 616 assigned by IANA using the "Expert Review" policy defined in RFC5226. 617 Type values 65536 through 134,217,728, 0 and 4,294,967,295 are to be 618 allocated using the IETF consensus policy defined in [RFC5226]. Type 619 values 134,217,729 through 4,294,967,294 are reserved for vendor 620 proprietary extensions and are to be assigned by IANA, using the 621 "First Come First Served" policy defined in RFC5226. 623 The Type Values are assigned as follows: 624 Code Error? Description 625 ---- ------ ----------- 626 0x00000000 No Null Notification. 627 0x00000001 No PW configuration rejected. 628 0x00000002 Yes PW Configuration TLV conflict. 629 0x00000003 No Unknown TLV (U-bit=1) 630 0x00000004 Yes Unknown TLV (U-bit=0) 631 0x00000005 No Unknown Message Type 632 0x00000006 No PW configuration not supported. 633 0x00000007 Yes Unacknowledged control message. 635 9. References 637 9.1. Normative References 639 [RFC2119] Bradner. S, "Key words for use in RFCs to 640 Indicate Requirement Levels", RFC 2119, March, 1997. 642 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 643 et al., rfc4447 April 2006. 645 [PW-STATUS] L. Martini, G. Swallow, G. Heron, M. Bocci "Pseudowire 646 Status for Static Pseudowires", 647 draft-ietf-pwe3-static-pw-status-06.txt, (work in progress), 648 July 2011 650 [IDENTIFIER] M. Bocci, G. Swallow, E. Gray "MPLS-TP Identifiers" 651 draft-ietf-mpls-tp-identifiers-07.txt, IETF Work in Progress, 652 july 2011 654 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 655 IANA Considerations section in RFCs", BCP 26, RFC 5226, May 2008 657 9.2. Informative References 659 [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed., 660 "MPLS Generic Associated Channel", rfc5586, June 2009 662 10. Author's Addresses 664 Luca Martini 665 Cisco Systems, Inc. 666 9155 East Nichols Avenue, Suite 400 667 Englewood, CO, 80112 668 e-mail: lmartini@cisco.com 670 George Swallow 671 Cisco Systems, Inc. 672 300 Beaver Brook Road 673 Boxborough, Massachusetts 01719 674 United States 675 e-mail: swallow@cisco.com 677 Elisa Bellagamba 678 Ericsson EAB 679 Torshamnsgatan 48 680 16480, Stockholm 681 Sweden 682 e-mail: elisa.bellagamba@ericsson.com 684 Copyright Notice 686 Copyright (c) 2013 IETF Trust and the persons identified as the 687 document authors. All rights reserved. 689 This document is subject to BCP 78 and the IETF Trust's Legal 690 Provisions Relating to IETF Documents 691 (http://trustee.ietf.org/license-info) in effect on the date of 692 publication of this document. Please review these documents 693 carefully, as they describe your rights and restrictions with respect 694 to this document. Code Components extracted from this document must 695 include Simplified BSD License text as described in Section 4.e of 696 the Trust Legal Provisions and are provided without warranty as 697 described in the Simplified BSD License. 699 Expiration Date: April 2014