idnits 2.17.1 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05.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 (January 10, 2013) is 4124 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) == Missing Reference: 'RFC6428' is mentioned on line 172, but not defined == Missing Reference: 'RFC6427' is mentioned on line 797, but not defined == Unused Reference: 'OAM-CONF-FWK' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 872, but no explicit reference was found in the text == Unused Reference: 'RFC5586' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC6420' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'ETH-OAM' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'RFC6435' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'RFC6669' is defined on line 937, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OAM-CONF-FWK' -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group E. Bellagamba, Ed. 3 Internet-Draft L. Andersson 4 Intended status: Standards Track Ericsson 5 Expires: July 14, 2013 P. Skoldstrom, Ed. 6 Acreo AB 7 D. Ward 8 Cisco 9 J. Drake 10 Juniper 11 January 10, 2013 13 Configuration of Pro-Active Operations, Administration, and Maintenance 14 (OAM) Functions for MPLS-based Transport Networks using LSP Ping 15 draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-05 17 Abstract 19 This specification describes the configuration of pro-active MPLS-TP 20 Operations, Administration, and Maintenance (OAM) Functions for a 21 given LSP using a set of TLVs that are carried by the LSP-Ping 22 protocol. 24 This document is a product of a joint Internet Engineering Task Force 25 (IETF) / International Telecommunication Union Telecommunication 26 Standardization Sector (ITU-T) effort to include an MPLS Transport 27 Profile within the IETF MPLS and PWE3 architectures to support the 28 capabilities and functionalities of a packet transport network. 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 July 14, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 4 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Overview of MPLS OAM for Transport Applications . . . . . . . 4 67 3. Theory of Operations . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. MPLS OAM Configuration Operation Overview . . . . . . . . 5 69 3.1.1. Configuration of BFD sessions . . . . . . . . . . . . 5 70 3.1.2. Configuration of Performance Monitoring . . . . . . . 6 71 3.1.3. Configuration of Fault Management Signals . . . . . . 6 72 3.2. OAM Functions TLV . . . . . . . . . . . . . . . . . . . . 7 73 3.2.1. BFD Configuration sub-TLV . . . . . . . . . . . . . . 8 74 3.2.1.1. Local Discriminator sub-TLV . . . . . . . . . . . 10 75 3.2.1.2. Negotiation Timer Parameters sub-TLV . . . . . . . 11 76 3.2.1.3. BFD Authentication sub-TLV . . . . . . . . . . . . 12 77 3.2.2. MPLS OAM Source MEP-ID sub-TLV . . . . . . . . . . . . 12 78 3.2.3. Performance Monitoring sub-TLV . . . . . . . . . . . . 13 79 3.2.3.1. MPLS OAM PM Loss sub-TLV . . . . . . . . . . . . . 14 80 3.2.3.2. MPLS OAM PM Delay sub-TLV . . . . . . . . . . . . 16 81 3.2.4. MPLS OAM FMS sub-TLV . . . . . . . . . . . . . . . . . 17 82 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 83 3.4. OAM configuration errors . . . . . . . . . . . . . . . . . 18 84 3.5. Security Considerations . . . . . . . . . . . . . . . . . 19 85 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 4.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 4.2. Informative References . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 90 1. Introduction 92 This document describes the configuration of pro-active MPLS-TP 93 Operations, Administration, and Maintenance (OAM) Functions for a 94 given LSP using TLVs carried in LSP-Ping [RFC4379]. In particular it 95 specifies the mechanisms necessary to establish MPLS-TP OAM entities 96 at the maintenance points for monitoring and performing measurements 97 on an LSP, as well as defining information elements and procedures to 98 configure pro-active MPLS-TP OAM functions running between LERs. 99 Initialization and control of on-demand MPLS-TP OAM functions are 100 expected to be carried out by directly accessing network nodes via a 101 management interface; hence configuration and control of on-demand 102 OAM functions are out-of-scope for this document. 104 The Transport Profile of MPLS must, by definition [RFC5654], be 105 capable of operating without a control plane. Therefore there are 106 several options for configuring MPLS-TP OAM, without a control plane 107 by either using an NMS or LSP Ping, or with a control plane using 108 signaling protocols RSVP-TE and/or T-LDP. 110 Pro-active MPLS-TP OAM is performed by four different protocols, Bi- 111 directional Forwarding Detection (BFD) [RFC6428] for Continuity 112 Check/Connectivity Verification, the delay measurement protocol (DM) 113 [RFC6374] for delay and delay variation (jitter) measurements, and 114 the loss measurement protocol (LM) [RFC6374] for packet loss and 115 throughput measurements. Additionally there is a number of Fault 116 Management Signals that can be configured. 118 BFD is a protocol that provides low-overhead, fast detection of 119 failures in the path between two forwarding engines, including the 120 interfaces, data link(s), and to the extent possible the forwarding 121 engines themselves. BFD can be used to track the liveliness and 122 detect data plane failures of MPLS-TP point-to-point and might also 123 be extended to support point-to-multipoint connections. 125 The delay and loss measurements protocols [RFC6374] use a simple 126 query/response model for performing bidirectional measurements that 127 allows the originating node to measure packet loss and delay in both 128 directions. By timestamping and/or writing current packet counters 129 to the measurement packets at four times (Tx and Rx in both 130 directions) current delays and packet losses can be calculated. By 131 performing successive delay measurements the delay variation (jitter) 132 can be calculated. Current throughput can be calculated from the 133 packet loss measurements by dividing the number of packets sent/ 134 received with the time it took to perform the measurement, given by 135 the timestamp in LM header. Combined with a packet generator the 136 throughput measurement can be used to measure the maximum capacity of 137 a particular LSP. It should be noted that here we are not 138 configuring on-demand throughput estimates based on saturating the 139 connection as defined in [RFC6371]. Rather, we only enable the 140 estimation of the current throughput based on loss measurements. 142 MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that 143 enables operational models typical in transport networks, while 144 providing additional OAM, survivability and other maintenance 145 functions not currently supported by MPLS. [RFC5860] defines the 146 requirements for the OAM functionality of MPLS-TP. 148 This document is a product of a joint Internet Engineering Task Force 149 (IETF) / International Telecommunication Union Telecommunication 150 Standardization Sector (ITU-T) effort to include an MPLS Transport 151 Profile within the IETF MPLS and PWE3 architectures to support the 152 capabilities and functionalities of a packet transport network. 154 1.1. Contributing Authors 156 This document is the result of a large team of authors and 157 contributors. The following is a list of the co-authors: 159 Gregory Mirsky 161 1.2. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 2. Overview of MPLS OAM for Transport Applications 169 [RFC6371] describes how MPLS-TP OAM mechanisms are operated to meet 170 transport requirements outlined in [RFC5860]. 172 [RFC6428] specifies two BFD operation modes: 1) "CC mode", which uses 173 periodic BFD message exchanges with symmetric timer settings, 174 supporting Continuity Check, 2) "CV/CC mode" which sends unique 175 maintenance entity identifiers in the periodic BFD messages 176 supporting Connectivity Verification as well as Continuity Check. 178 [RFC6374] specifies mechanisms for performance monitoring of LSPs, in 179 particular it specifies loss and delay measurement OAM functions. 181 [RFC6427] specifies fault management signals with which a server LSP 182 can notify client LSPs about various fault conditions to suppress 183 alarms or to be used as triggers for actions in the client LSPs. The 184 following signals are defined: Alarm Indication Signal (AIS), Link 185 Down Indication (LDI) and Lock Report (LKR). 187 [RFC6371] describes the mapping of fault conditions to consequent 188 actions. Some of these mappings may be configured by the operator, 189 depending on the application of the LSP. The following defects are 190 identified: Loss Of Continuity (LOC), Misconnectivity, MEP 191 Misconfiguration and Period Misconfiguration. Out of these defect 192 conditions, the following consequent actions may be configurable: 1) 193 whether or not the LOC defect should result in blocking the outgoing 194 data traffic; 2) whether or not the "Period Misconfiguration defect" 195 should result in a signal fail condition. 197 3. Theory of Operations 199 3.1. MPLS OAM Configuration Operation Overview 201 LSP Ping, or alternatively RSVP-TE [RSVP-TE-CONF], can be used to 202 simply enable the different OAM functions, by setting the 203 corresponding flags in the "OAM Functions TLV". For a more detailed 204 configuration one may include sub-TLVs for the different OAM 205 functions in order to specify various parameters in detail. 207 Typically intermediate nodes should not process or modify any of the 208 OAM configuration TLVs but simply forward them to the end-node. 209 There is one exception to this and that is if the "MPLS OAM FMS sub- 210 TLV" is present. This sub-TLV has to be examined even by 211 intermediate nodes. The sub-TLV MAY be present if a flag is set in 212 the "OAM Functions TLV". 214 3.1.1. Configuration of BFD sessions 216 For this specification, BFD MUST be run in either one of the two 217 modes: 219 - Asynchronous mode, where both sides should be in active mode 221 - Unidirectional mode 223 In the simplest scenario LSP Ping, or alternatively RSVP-TE [RSVP-TE 224 CONF], is used only to bootstrap a BFD session for an LSP, without 225 any timer negotiation. 227 Timer negotiation can be performed either in subsequent BFD control 228 messages (in this case the operation is similar to LSP Ping based 229 bootstrapping described in [RFC5884]) or directly in the LSP-Ping 230 configuration messages. 232 When BFD Control packets are transported in the G-ACh they are not 233 protected by any end-to-end checksum, only lower-layers are providing 234 error detection/correction. A single bit error, e.g. a flipped bit 235 in the BFD State field could cause the receiving end to wrongly 236 conclude that the link is down and in turn trigger protection 237 switching. To prevent this from happening the "BFD Configuration 238 sub-TLV" has an Integrity flag that when set enables BFD 239 Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. 240 This would make every BFD Control packet carry an SHA1 hash of itself 241 that can be used to detect errors. 243 If BFD Authentication using a pre-shared key / password is desired 244 (i.e. authentication and not only error detection) the "BFD 245 Authentication sub-TLV" MUST be included in the "BFD Configuration 246 sub-TLV". The "BFD Authentication sub-TLV" is used to specify which 247 authentication method that should be used and which pre-shared key / 248 password that should be used for this particular session. How the 249 key exchange is performed is out of scope of this document. 251 3.1.2. Configuration of Performance Monitoring 253 It is possible to configure Performance Monitoring functionalities 254 such as Loss, Delay, Delay variation (jitter), and Throughput as 255 described in [RFC6374]. 257 When configuring Performance monitoring functionalities it is 258 possible to choose either the default configuration, by only setting 259 the respective flags in the "OAM functions TLV", or a customized 260 configuration. To customize the configuration one would set the 261 respective flags in the including the respective Loss and/or Delay 262 sub-TLVs). 264 By setting the PM Loss flag in the "OAM Functions TLV" and including 265 the "MPLS OAM PM Loss sub-TLV" one can configure the measurement 266 interval and loss threshold values for triggering protection. 268 Delay measurements are configured by setting PM Delay flag in the 269 "OAM Functions TLV" and including the "MPLS OAM PM Loss sub-TLV" one 270 can configure the measurement interval and the delay threshold values 271 for triggering protection. 273 3.1.3. Configuration of Fault Management Signals 275 To configure Fault Monitoring Signals and their refresh time the FMS 276 flag in the "OAM Functions TLV" MUST be set and the "MPLS OAM FMS 277 sub-TLV" included. When configuring Fault Monitoring Signals it can 278 be chosen either the default configuration (by only setting the 279 respective flags in the "OAM functions TLV") or a customized 280 configuration (by including the "MPLS OAM FMS sub-TLV"). 282 If an intermediate point is meant to originate fault management 283 signal messages this means that such an intermediate point is 284 associated to a server MEP through a co-located MPLS-TP client/server 285 adaptation function. Such a server MEP needs to be configured by its 286 own LSP-ping session (or, alternatively, via an NMS or RSVP-TE). 287 However, by setting the "Fault Management subscription" flag in the 288 "MPLS OAM FMS sub-TLV" a client LSP can indicate that it would like 289 an association to be created to the server MEP(s) on any intermediate 290 nodes. 292 3.2. OAM Functions TLV 294 The "OAM Functions TLV" depicted below is carried as a TLV of the LSP 295 Echo request/response messages. 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | OAM Func. Type (16) (IANA) | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |C|V|L|D|F| OAM Function Flags | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 ~ sub-TLVs ~ 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 The "OAM Functions TLV" contains a number of flags indicating which 310 OAM functions should be activated as well as OAM function specific 311 sub-TLVs with configuration parameters for the particular function. 313 Type: indicates a new type, the "OAM Functions TLV" (IANA to define, 314 suggested value 16). 316 Length: the length of the OAM Function Flags field including the 317 total length of the sub-TLVs in octets. 319 OAM Function Flags: a bitmap numbered from left to right as shown in 320 the figure. 322 These flags are defined in this document: 324 OAM Function Flag bit# Description 325 --------------------- --------------------------- 326 0 (C) Continuity Check (CC) 327 1 (V) Connectivity Verification (CV) 328 2 (F) Fault Management Signals (FMS) 329 3 (L) Performance Monitoring/Loss (PM/Loss) 330 4 (D) Performance Monitoring/Delay (PM/Delay) 331 5 (T) Throughput Measurement 332 6-31 Reserved (set all to 0s) 334 Sub-TLVs corresponding to the different flags are as follows: 336 - "BFD Configuration sub-TLV", which MUST be included if the CC 337 and/or the CV OAM Function flag is set. This sub-TLV MUST carry a 338 "BFD Local Discriminator sub-TLV" and a "Timer Negotiation 339 Parameters sub-TLV" if the N flag is cleared. The "MPLS OAM 340 Source MEP-ID sub-TLV" MUST also be included. If the I flag is 341 set, the "BFD Authentication sub-TLV" may be included. 343 - "MPLS OAM PM Loss sub-TLV" within the "Performance Monitoring 344 sub-TLV", which MAY be included if the PM/Loss OAM Function flag 345 is set. If the "MPLS OAM PM Loss sub-TLV" is not included, 346 default configuration values are used. Such sub-TLV MAY also be 347 included in case the Throughput function flag is set and there is 348 the need to specify measurement interval different from the 349 default ones. In fact the throughput measurement make use of the 350 same tool as the loss measurement, hence the same TLV is used. 352 - "MPLS OAM PM Delay sub-TLV" within the "Performance Monitoring 353 sub-TLV", which MAY be included if the PM/Delay OAM Function flag 354 is set. If the "MPLS OAM PM Delay sub-TLV" is not included, 355 default configuration values are used. 357 - "MPLS OAM FMS sub-TLV", which MAY be included if the FMS OAM 358 Function flag is set. If the "MPLS OAM FMS sub-TLV" is not 359 included, default configuration values are used. 361 3.2.1. BFD Configuration sub-TLV 363 The "BFD Configuration sub-TLV" (depicted below) is defined for BFD 364 OAM specific configuration parameters. The "BFD Configuration sub- 365 TLV" is carried as a sub-TLV of the "OAM Functions TLV". 367 This TLV accommodates generic BFD OAM information and carries sub- 368 TLVs. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | BFD Conf. Type (1) (IANA) | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |Vers.| PHB |N|S|I|G|U|B| Reserved (set to all 0s) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 ~ sub-TLVs ~ 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to 383 define, suggested value 1). 385 Length: indicates the length of the TLV including sub-TLVs but 386 excluding the Type and Length field, in octets. 388 Version: identifies the BFD protocol version. If a node does not 389 support a specific BFD version an error must be generated: "OAM 390 Problem/Unsupported OAM Version". 392 PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic 393 continuity monitoring messages. 395 BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 396 Control Messages is enabled, when cleared it is disabled. 398 Symmetric session (S): If set the BFD session MUST use symmetric 399 timing values. 401 Integrity (I): If set BFD Authentication MUST be enabled. If the 402 "BFD Configuration sub-TLV" does not include a "BFD Authentication 403 sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre- 404 shared key (all 0s). 406 Encapsulation Capability (G): if set, it shows the capability of 407 encapsulating BFD messages into G-Ach channel. If both the G bit and 408 U bit are set, configuration gives precedence to the G bit. 410 Encapsulation Capability (U): if set, it shows the capability of 411 encapsulating BFD messages into UDP packets. If both the G bit and U 412 bit are set, configuration gives precedence to the G bit. 414 Bidirectional (B): if set, it configures BFD in the Bidirectional 415 mode. If it is not set it configures BFD in unidirectional mode. In 416 the second case, the source node does not expect any Discriminator 417 values back from the destination node. 419 Reserved: Reserved for future specification and set to 0 on 420 transmission and ignored when received. 422 The "BFD Configuration sub-TLV" MUST include the following sub-TLVs 423 in the LSP Echo request message: 425 - "Local Discriminator sub-TLV"; 427 - "Negotiation Timer Parameters sub-TLV" if the N flag is cleared. 429 The "BFD Configuration sub-TLV" MUST include the following sub-TLVs 430 in the LSP Echo reply message: 432 - "Local Discriminator sub-TLV;" 434 - "Negotiation Timer Parameters sub-TLV" if: 436 - the N and S flags are cleared, or if: 438 - the N flag is cleared and the S flag is set, and the 439 Negotiation Timer Parameters sub-TLV received by the egress 440 contains unsupported values. In this case an updated 441 Negotiation Timer Parameters sub-TLV, containing values 442 supported by the egress node, is returned to the ingress. 444 3.2.1.1. Local Discriminator sub-TLV 446 The "Local Discriminator sub-TLV" is carried as a sub-TLV of the "BFD 447 Configuration sub-TLV" and is depicted below. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Lcl. Discr. Type (1) (IANA) | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Local Discriminator | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Type: indicates a new type, the "Local Discriminator sub-TLV" (IANA 458 to define, suggested value 1). 460 Length: indicates the TLV length in octets, excluding the Type and 461 Length field. (4) 463 Local Discriminator: A unique, nonzero discriminator value generated 464 by the transmitting system and referring to itself, used to 465 demultiplex multiple BFD sessions between the same pair of systems. 467 3.2.1.2. Negotiation Timer Parameters sub-TLV 469 The "Negotiation Timer Parameters sub-TLV" is carried as a sub-TLV of 470 the "BFD Configuration sub-TLV" and is depicted below. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Nego. Timer Type (2) (IANA) | Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Acceptable Min. Asynchronous TX interval | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Acceptable Min. Asynchronous RX interval | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Required Echo TX Interval | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Type: indicates a new type, the "Negotiation Timer Parameters sub- 485 TLV" (IANA to define, suggested value 2). 487 Length: indicates the length of the parameters in octets (12). 489 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 490 flag set in the "BFD Configuration sub-TLV", it expresses the desired 491 time interval (in microseconds) at which the ingress LER intends to 492 both transmit and receive BFD periodic control packets. If the 493 receiving edge LSR can not support such value, it SHOULD reply with 494 an interval greater than the one proposed. 496 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 497 TLV", this field expresses the desired time interval (in 498 microseconds) at which a edge LSR intends to transmit BFD periodic 499 control packets in its transmitting direction. 501 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 502 flag set in the "BFD Configuration sub-TLV", this field MUST be equal 503 to "Acceptable Min. Asynchronous TX interval" and has no additional 504 meaning respect to the one described for "Acceptable Min. 505 Asynchronous TX interval". 507 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 508 TLV", it expresses the minimum time interval (in microseconds) at 509 which edge LSRs can receive BFD periodic control packets. In case 510 this value is greater than the "Acceptable Min. Asynchronous TX 511 interval" received from the other edge LSR, such edge LSR MUST adopt 512 the interval expressed in this "Acceptable Min. Asynchronous RX 513 interval". 515 Required Echo TX Interval: the minimum interval (in microseconds) 516 between received BFD Echo packets that this system is capable of 517 supporting, less any jitter applied by the sender as described in 518 [RFC5880] sect. 6.8.9. This value is also an indication for the 519 receiving system of the minimum interval between transmitted BFD Echo 520 packets. If this value is zero, the transmitting system does not 521 support the receipt of BFD Echo packets. If the receiving system can 522 not support this value the "Unsupported BFD TX Echo rate interval" 523 error MUST be generated. By default the value is set to 0. 525 3.2.1.3. BFD Authentication sub-TLV 527 The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD 528 Configuration sub-TLV" and is depicted below. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | BFD Auth. Type (3) (IANA) | Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Auth Type | Auth Key ID | Reserved (0s) | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Type: indicates a new type, the "BFD Authentication sub-TLV" (IANA to 539 define). 541 Length: indicates the TLV total length in octets, exluding the Type 542 and Length fields. (4) 544 Auth Type: indicates which type of authentication to use. The same 545 values as are defined in section 4.1 of [RFC5880] are used. 547 Auth Key ID: indicates which authentication key or password 548 (depending on Auth Type) should be used. How the key exchange is 549 performed is out of scope of this document. 551 Reserved: Reserved for future specification and set to 0 on 552 transmission and ignored when received. 554 3.2.2. MPLS OAM Source MEP-ID sub-TLV 556 The "MPLS OAM Source MEP-ID sub-TLV" depicted below is carried as a 557 sub-TLV of the "OAM Functions TLV". 559 Note that support of ITU IDs is out-of-scope. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Source MEP-ID Type (4) (IANA) | Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Source Node ID | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Tunnel ID | LSP ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Type: indicates a new type, the "MPLS OAM Source MEP-ID sub-TLV" 572 (IANA to define, suggested value 3). 574 Length: indicates the length of the TLV in octets, excluding the Type 575 and Length fields. (8) 577 Source Node ID: 32-bit node identifier as defined in [RFC6370]. 579 Tunnel ID: a 16-bit unsigned integer unique to the node as defined in 580 [RFC6370]. 582 LSP ID: a 16-bit unsigned integer unique within the Tunnel_ID as 583 defined in [RFC6370]. 585 3.2.3. Performance Monitoring sub-TLV 587 If the "OAM functions TLV" has either the L (Loss), D (Delay) or T 588 (Throughput) flag set, the "Performance Monitoring sub-TLV" MUST be 589 present. 591 The "Performance Monitoring sub-TLV" provides the configuration 592 information mentioned in Section 7 of [RFC6374]. It includes support 593 for the configuration of quality thresholds and, as described in 594 [RFC6374], "the crossing of which will trigger warnings or alarms, 595 and result reporting and exception notification will be integrated 596 into the system-wide network management and reporting framework." 598 In case the values need to be different than the default ones the 599 "Performance Monitoring sub-TLV", "MPLS OAM PM Loss sub-TLV" MAY 600 include the following sub-TLVs: 602 - "MPLS OAM PM Loss sub-TLV" if the L flag is set in the "OAM 603 functions TLV"; 605 - "MPLS OAM PM Delay sub-TLV" if the D flag is set in the "OAM 606 functions TLV"; 608 The "Performance Monitoring sub-TLV" depicted below is carried as a 609 sub-TLV of the "OAM Functions TLV". 611 0 1 2 3 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Perf Monitoring Type (2)(IANA)| Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |D|L|J|Y|K|C| Reserved (set to all 0s) | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 ~ sub-TLVs ~ 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Type: indicates a new type, the "Performance Monitoring sub-TLV" 624 (IANA to define, suggested value 2). 626 Length: indicates the TLV length in octets, exluding the Type and 627 Length fields. 629 Configuration Flags, for the specific function description please 630 refer to [RFC6374]: 632 - D: Delay inferred/direct (0=INFERRED, 1=DIRECT) 634 - L: Loss inferred/direct (0=INFERRED, 1=DIRECT) 636 - J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE) 638 - Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE) 640 - K: Loopback (1=ACTIVE, 0=NOT ACTIVE) 642 - C: Combined (1=ACTIVE, 0=NOT ACTIVE) 644 Reserved: Reserved for future specification and set to 0 on 645 transmission and ignored when received. 647 3.2.3.1. MPLS OAM PM Loss sub-TLV 649 The "MPLS OAM PM Loss sub-TLV" depicted below is carried as a sub-TLV 650 of the "Performance Monitoring sub-TLV". 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | PM Loss Type (1) (IANA) | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | OTF |T|B| Reserved (set to all 0s) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Measurement Interval | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Test Interval | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Loss Threshold | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Type: indicates a new type, the "MPLS OAM PM Loss sub-TLV" (IANA to 667 define, suggested value 1). 669 Length: indicates the length of the parameters in octets (16). 671 OTF: Origin Timestamp Format of the Origin Timestamp field described 672 in [RFC6374]. By default it is set to IEEE 1588 version 1. 674 Configuration Flags, please refer to [RFC6374] for further details: 676 - T: Traffic-class-specific measurement indicator. Set to 1 when 677 the measurement operation is scoped to packets of a particular 678 traffic class (DSCP value), and 0 otherwise. When set to 1, the 679 DS field of the message indicates the measured traffic class. By 680 default it is set to 1. 682 - B: Octet (byte) count. When set to 1, indicates that the 683 Counter 1-4 fields represent octet counts. When set to 0, 684 indicates that the Counter 1-4 fields represent packet counts. By 685 default it is set to 0. 687 Reserved: Reserved for future specification and set to 0 on 688 transmission and ignored when received. 690 Measurement Interval: the time interval (in milliseconds) at which 691 Loss Measurement query messages MUST be sent on both directions. If 692 the edge LSR receiving the Path message can not support such value, 693 it SHOULD reply with a higher interval. By default it is set to 694 (100) as per [RFC6375]. 696 Test Interval: test messages interval in milliseconds as described in 697 [RFC6374]. By default it is set to (10) as per [RFC6375]. 699 Loss Threshold: the threshold value of measured lost packets per 700 measurement over which action(s) SHOULD be triggered. 702 3.2.3.2. MPLS OAM PM Delay sub-TLV 704 The "MPLS OAM PM Delay sub-TLV" depicted below is carried as a sub- 705 TLV of the "Performance Monitoring sub-TLV". 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | PM Delay Type (2) (IANA) | Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | OTF |T|B| Reserved (set to all 0s) | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Measurement Interval | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Test Interval | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Delay Threshold | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Type: indicates a new type, the "MPLS OAM PM Loss sub-TLV" (IANA to 722 define, suggested value 2). 724 Length: indicates the length of the parameters in octets (16). 726 OTF: Origin Timestamp Format of the Origin Timestamp field described 727 in [RFC6374]. By default it is set to IEEE 1588 version 1. 729 Configuration Flags, please refer to [RFC6374] for further details: 731 - T: Traffic-class-specific measurement indicator. Set to 1 when 732 the measurement operation is scoped to packets of a particular 733 traffic class (DSCP value), and 0 otherwise. When set to 1, the 734 DS field of the message indicates the measured traffic class. By 735 default it is set to 1. 737 - B: Octet (byte) count. When set to 1, indicates that the 738 Counter 1-4 fields represent octet counts. When set to 0, 739 indicates that the Counter 1-4 fields represent packet counts. By 740 default it is set to 0. 742 Reserved: Reserved for future specification and set to 0 on 743 transmission and ignored when received. 745 Measurement Interval: the time interval (in milliseconds) at which 746 Delay Measurement query messages MUST be sent on both directions. If 747 the edge LSR receiving the Path message can not support such value, 748 it can reply with a higher interval. By default it is set to (1000) 749 as per [RFC6375]. 751 Test Interval: test messages interval (in milliseconds) as described 752 in [RFC6374]. By default it is set to (10) as per [RFC6375]. 754 Delay Threshold: the threshold value of measured two-way delay (in 755 milliseconds) over which action(s) SHOULD be triggered. 757 3.2.4. MPLS OAM FMS sub-TLV 759 The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TLV of 760 the "OAM Configuration sub-TLV". When both working and protection 761 paths are configured, both LSPs SHOULD be configured with identical 762 settings of the E flag, T flag, and the refresh timer. 764 0 1 2 3 765 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 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | MPLS OAM FMS Type (3) (IANA) | Length | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 |E|S|T| Reserved (set to all 0s)| Refresh Timer | PHB | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to 773 define, suggested value 3). 775 Length: indicates the length of the parameters in octets (4). 777 FMS Signal Flags are used to enable the FMS signals at end point MEPs 778 and the Server MEPs of the links over which the LSP is forwarded. In 779 this document only the S flag pertains to Server MEPs. 781 The following flags are defined: 783 - E: Enable Alarm Indication Signal (AIS) and Lock Report (LKR) 784 signalling as described in [RFC6427]. Default value is 1 785 (enabled). 787 - S: Indicate to a server MEP that its should transmit AIS and LKR 788 signals on the client LSP. Default value is 0 (disabled). 790 - T: Set timer value, enabled the configuration of a specific 791 timer value. Default value is 0 (disabled). 793 - Remaining bits: Reserved for future specification and set to 0. 795 Refresh Timer: indicates the refresh timer of fault indication 796 messages, in seconds. The value MUST be between 1 to 20 seconds as 797 specified for the Refresh Timer field in [RFC6427]. If the edge LSR 798 receiving the Path message can not support the value it SHOULD reply 799 with a higher timer value. 801 PHB: identifies the per-hop behavior of packets with fault management 802 information. 804 3.3. IANA Considerations 806 This document specifies the following new TLV types: 808 - "OAM Functions" type: 16; 810 sub-TLV types to be carried in the "OAM Functions TLV": 812 - "BFD Configuration" type: 1; 814 - "MPLS OAM Performance Monitoring" type: 2; 816 - "MPLS OAM FMS" type: 3; 818 - "MPLS OAM Source MEP-ID" type: 4. 820 sub-TLV types to be carried in the "BFD Configuration sub-TLV": 822 - "Local Discriminator" type: 1; 824 - "Negotiation Timer Parameters" type: 2; 826 - "BFD Authentication" sub-TLV type: 3. 828 sub-TLV types to be carried in the "Performance monitoring sub-TLV": 830 - "MPLS OAM PM Loss" type: 1; 832 - "MPLS OAM PM Delay" type: 2; 834 3.4. OAM configuration errors 836 This document specifies additional Return Codes to LSP Ping: 838 - "MPLS OAM Unsupported Functionality"; 839 - "OAM Problem/Unsupported TX rate interval"; 841 - "OAM Problem/Unsupported RX rate interval"; 843 - "OAM Problem/Unsupported unsupported Authentication Type"; 845 - "OAM Problem, mismatch of Authentication Key ID ". 847 3.5. Security Considerations 849 The signaling of OAM related parameters and the automatic 850 establishment of OAM entities introduces additional security 851 considerations to those discussed in [RFC3473]. In particular, a 852 network element could be overloaded if an attacker were to request 853 high frequency liveliness monitoring of a large number of LSPs, 854 targeting a single network element. 856 4. References 858 4.1. Normative References 860 [OAM-CONF-FWK] 861 Takacs, A., Fedyk, D., and J. van He, "OAM Configuration 862 Framework for GMPLS RSVP-TE", 2009, 863 . 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, March 1997. 868 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 869 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 870 Tunnels", RFC 3209, December 2001. 872 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 873 (GMPLS) Signaling Functional Description", RFC 3471, 874 January 2003. 876 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 877 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 878 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 880 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 881 Associated Channel", RFC 5586, June 2009. 883 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 884 and S. Ueno, "Requirements of an MPLS Transport Profile", 885 RFC 5654, September 2009. 887 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 888 Operations, Administration, and Maintenance (OAM) in MPLS 889 Transport Networks", RFC 5860, May 2010. 891 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 892 (BFD)", RFC 5880, June 2010. 894 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 895 "Bidirectional Forwarding Detection (BFD) for MPLS Label 896 Switched Paths (LSPs)", RFC 5884, June 2010. 898 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 899 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 901 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 902 Measurement for MPLS Networks", RFC 6374, September 2011. 904 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 905 Attribute", RFC 6420, November 2011. 907 4.2. Informative References 909 [ETH-OAM] Takacs, A., Gero, B., and H. Long, "GMPLS RSVP-TE 910 Extensions for Ethernet OAM Configuration", 2012, 911 . 913 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 914 Label Switched (MPLS) Data Plane Failures", RFC 4379, 915 February 2006. 917 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 918 Heron, "Pseudowire Setup and Maintenance Using the Label 919 Distribution Protocol (LDP)", RFC 4447, April 2006. 921 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 922 Berger, "A Framework for MPLS in Transport Networks", 923 RFC 5921, July 2010. 925 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 926 Maintenance Framework for MPLS-Based Transport Networks", 927 RFC 6371, September 2011. 929 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 930 Measurement Profile for MPLS-Based Transport Networks", 931 RFC 6375, September 2011. 933 [RFC6435] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 934 and X. Dai, "MPLS Transport Profile Lock Instruct and 935 Loopback Functions", RFC 6435, November 2011. 937 [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, 938 Administration, and Maintenance (OAM) Toolset for MPLS- 939 Based Transport Networks", RFC 6669, July 2012. 941 [RSVP-TE-CONF] 942 Bellagamba, E., Andersson, L., Ward, D., and P. 943 Skoldstrom, "Configuration of pro-active MPLS-TP 944 Operations, Administration, and Maintenance (OAM) 945 Functions Using RSVP-TE", 2012, 946 . 948 Authors' Addresses 950 Elisa Bellagamba (editor) 951 Ericsson 952 Torshamnsgatan 48 953 Kista, 164 40 954 Sweden 956 Email: elisa.bellagamba@ericsson.com 958 Loa Andersson 959 Ericsson 960 Torshamnsgatan 48 961 Kista, 164 40 962 Sweden 964 Phone: 965 Email: loa.andersson@ericsson.com 967 Pontus Skoldstrom (editor) 968 Acreo AB 969 Electrum 236 970 Kista, 164 40 971 Sweden 973 Phone: +46 8 6327731 974 Email: pontus.skoldstrom@acreo.se 975 Dave Ward 976 Cisco 978 Phone: 979 Email: dward@cisco.com 981 John Drake 982 Juniper 984 Phone: 985 Email: jdrake@juniper.net