idnits 2.17.1 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09.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 7, 2012) is 4220 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: 'LSP-PING CONF' is mentioned on line 206, but not defined == Unused Reference: 'RFC3471' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC5586' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC6375' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'BFD-Ping' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'LSP-PING-CONF' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'MPLS-TP-OAM-Analysis' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC4379' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 953, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-FMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-IDENTIF' -- Possible downref: Non-RFC (?) normative reference: ref. 'OAM-CONF-FWK' ** Downref: Normative reference to an Informational RFC: RFC 6375 -- 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: 1 error (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group E. Bellagamba, Ed. 3 Internet-Draft L. Andersson, Ed. 4 Intended status: Standards Track Ericsson 5 Expires: April 10, 2013 P. Skoldstrom, Ed. 6 Acreo AB 7 D. Ward 8 Juniper 9 A. Takacs 10 Ericsson 11 October 7, 2012 13 Configuration of Pro-Active Operations, Administration, and Maintenance 14 (OAM) Functions for MPLS-based Transport Networks using RSVP-TE 15 draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-09 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 RSVP-TE 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 April 10, 2013. 47 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . 7 72 3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7 73 3.3. BFD Configuration sub-TLV . . . . . . . . . . . . . . . . 9 74 3.3.1. Local Discriminator sub-TLV . . . . . . . . . . . . . 11 75 3.3.2. Negotiation Timer Parameters sub-TLV . . . . . . . . . 11 76 3.3.3. BFD Authentication sub-TLV . . . . . . . . . . . . . . 13 77 3.4. Performance Monitoring sub-TLV . . . . . . . . . . . . . . 13 78 3.4.1. MPLS OAM PM Loss sub-TLV . . . . . . . . . . . . . . . 14 79 3.4.2. MPLS OAM PM Delay sub-TLV . . . . . . . . . . . . . . 16 80 3.5. MPLS OAM FMS sub-TLV . . . . . . . . . . . . . . . . . . . 17 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 5. BFD OAM configuration errors . . . . . . . . . . . . . . . . . 18 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 8.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 by RSVP-TE [RFC3209]. 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 OAM functions running between LERs. 99 Initialization and control of on-demand MPLS 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. Use of T-LDP for 109 configuration of MPLS-TP OAM is outside of scope of this document. 111 Pro-active MPLS OAM is performed by three different protocols, 112 Bidirectional Forwarding Detection (BFD) [RFC6428] for Continuity 113 Check/Connectivity Verification, the delay measurement protocol (DM) 114 [RFC6374] for delay and delay variation (jitter) measurements, and 115 the loss measurement protocol (LM) [RFC6374] for packet loss and 116 throughput measurements. Additionally there is a number of Fault 117 Management Signals that can be configured. 119 BFD is a protocol that provides low-overhead, fast detection of 120 failures in the path between two forwarding engines, including the 121 interfaces, data link(s), and to the extent possible the forwarding 122 engines themselves. BFD can be used to track the liveliness and 123 detect data plane failures of MPLS-TP point-to-point and might also 124 be extended to support point-to-multipoint connections. 126 The delay and loss measurements protocols [RFC6374] use a simple 127 query/response model for performing bidirectional measurements that 128 allows the originating node to measure packet loss and delay in both 129 directions. By timestamping and/or writing current packet counters 130 to the measurement packets at four times (Tx and Rx in both 131 directions) current delays and packet losses can be calculated. By 132 performing successive delay measurements the delay variation (jitter) 133 can be calculated. Current throughput can be calculated from the 134 packet loss measurements by dividing the number of packets sent/ 135 received with the time it took to perform the measurement, given by 136 the timestamp in LM header. Combined with a packet generator the 137 throughput measurement can be used to measure the maximum capacity of 138 a particular LSP. 140 MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that 141 enables operational models typical in transport networks, while 142 providing additional OAM, survivability and other maintenance 143 functions not currently supported by MPLS. [RFC5860] defines the 144 requirements for the OAM functionality of MPLS-TP. 146 This document is a product of a joint Internet Engineering Task Force 147 (IETF) / International Telecommunication Union Telecommunication 148 Standardization Sector (ITU-T) effort to include an MPLS Transport 149 Profile within the IETF MPLS and PWE3 architectures to support the 150 capabilities and functionalities of a packet transport network. 152 1.1. Contributing Authors 154 This document is the result of a large team of authors and 155 contributors. The following is a list of the co-authors: 157 Gregory Mirsky 159 John Drake 161 Benoit Tremblay 163 1.2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 2. Overview of MPLS OAM for Transport Applications 171 [MPLS-TP-OAM-FWK] describes how MPLS OAM mechanisms are operated to 172 meet transport requirements outlined in [RFC5860]. 174 [BFD-CCCV] specifies two BFD operation modes: 1) "CC mode", which 175 uses periodic BFD message exchanges with symmetric timer settings, 176 supporting Continuity Check, 2) "CV/CC mode" which sends unique 177 maintenance entity identifiers in the periodic BFD messages 178 supporting Connectivity Verification as well as Continuity Check. 180 [RFC6374] specifies mechanisms for performance monitoring of LSPs, in 181 particular it specifies loss and delay measurement OAM functions. 183 [MPLS-FMS] specifies fault management signals with which a server LSP 184 can notify client LSPs about various fault conditions to suppress 185 alarms or to be used as triggers for actions in the client LSPs. The 186 following signals are defined: Alarm Indication Signal (AIS), Link 187 Down Indication (LDI) and Locked Report (LKR). To indicate client 188 faults associated with the attachment circuits Client Signal Failure 189 Indication (CSF) can be used. CSF is described in [MPLS-TP-OAM-FWK] 190 and in the context of this document is for further study. 192 [MPLS-TP-OAM-FWK] describes the mapping of fault conditions to 193 consequent actions. Some of these mappings may be configured by the 194 operator, depending on the application of the LSP. The following 195 defects are identified: Loss Of Continuity (LOC), Misconnectivity, 196 MEP Misconfiguration and Period Misconfiguration. Out of these 197 defect conditions, the following consequent actions may be 198 configurable: 1) whether or not the LOC defect should result in 199 blocking the outgoing data traffic; 2) whether or not the "Period 200 Misconfiguration defect" should result in a signal fail condition. 202 3. Theory of Operations 204 3.1. MPLS OAM Configuration Operation Overview 206 RSVP-TE, or alternatively LSP Ping [LSP-PING CONF], can be used to 207 simply enable the different OAM functions, by setting the 208 corresponding flags in the "OAM Functions TLV". For a more detailed 209 configuration one may include sub-TLVs for the different OAM 210 functions in order to specify various parameters in detail. 212 Typically intermediate nodes should not process or modify any of the 213 OAM configuration TLVs but simply forward them to the end-node. 214 There is one exception to this and that is if the "MPLS OAM FMS sub- 215 TLV" is present. This sub-TLV has to be examined even by 216 intermediate nodes. The sub-TLV MAY be present if a flag is set in 217 the "Function Flags sub-TLV", see section [3.2. OAM Configuration 218 TLV]. 220 3.1.1. Configuration of BFD sessions 222 For this specification, BFD MUST be run in either one of the two 223 modes: 225 - Asynchronous mode, where both sides should be in active mode 227 - Unidirectional mode 229 In the simplest scenario LSP Ping, or alternatively RSVP-TE [RSVP-TE 230 CONF], is used only to bootstrap a BFD session for an LSP, without 231 any timer negotiation. 233 Timer negotiation can be performed either in subsequent BFD control 234 messages (in this case the operation is similar to LSP Ping based 235 bootstrapping described in [RFC5884]) or directly in the LSP ping 236 configuration messages. 238 When BFD Control packets are transported in the G-ACh they are not 239 protected by any end-to-end checksum, only lower-layers are providing 240 error detection/correction. A single bit error, e.g. a flipped bit 241 in the BFD State field could cause the receiving end to wrongly 242 conclude that the link is down and in turn trigger protection 243 switching. To prevent this from happening the "BFD Configuration 244 sub-TLV" has an Integrity flag that when set enables BFD 245 Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880]. 246 This would make every BFD Control packet carry an SHA1 hash of itself 247 that can be used to detect errors. 249 If BFD Authentication using a pre-shared key / password is desired 250 (i.e. authentication and not only error detection) the "BFD 251 Authentication sub-TLV" MUST be included in the "BFD Configuration 252 sub-TLV". The "BFD Authentication sub-TLV" is used to specify which 253 authentication method that should be used and which pre-shared key / 254 password that should be used for this particular session. How the 255 key exchange is performed is out of scope of this document. 257 3.1.2. Configuration of Performance Monitoring 259 It is possible to configure Performance Monitoring functionalities 260 such as Loss, Delay and Throughput as described in [RFC6374]. 262 When configuring Performance monitoring functionalities it is 263 possible to choose either the default configuration, by only setting 264 the respective flags in the "OAM functions TLV", or a customized 265 configuration. To customize the configuration one would set the 266 respective flags in the including the respective Loss and/or Delay 267 sub-TLVs). 269 By setting the PM Loss flag in the "OAM Functions TLV" and including 270 the "MPLS OAM PM Loss sub-TLV" one can configure the measurement 271 interval and loss threshold values for triggering protection. 273 Delay measurements are configured by setting PM Delay flag in the 274 "OAM Functions TLV" and including the "MPLS OAM PM Loss sub-TLV" one 275 can configure the measurement interval and the delay threshold values 276 for triggering protection. 278 3.1.3. Configuration of Fault Management Signals 280 To configure Fault Monitoring Signals and their refresh time the FMS 281 flag in the "OAM Functions TLV" MUST be set and the "MPLS OAM FMS 282 sub-TLV" included. When configuring Fault Monitoring Signals it can 283 be chosen either the default configuration (by only setting the 284 respective flags in the "OAM functions TLV") or a customized 285 configuration (by including the "MPLS OAM FMS sub-TLV"). 287 If an intermediate point is meant to originate fault management 288 signal messages this means that such an intermediate point is 289 associated to a server MEP through a co-located MPLS-TP client/server 290 adaptation function. Such a server MEP needs to be configured by its 291 own RSVP-TE session (or, alternatively, via an NMS or LSP-ping). 292 However, by setting the "Fault Management subscription" flag in the 293 "MPLS OAM FMS sub-TLV" a client LSP can indicate that it would like 294 an association to be created to the server MEP(s) on any intermediate 295 nodes. 297 3.2. OAM Configuration TLV 299 The "OAM Configuration TLV" is depicted in the following figure. It 300 specifies the OAM functions that are to be used for the LSP and it is 301 defined in [OAM-CONF-FWK]. The "OAM Configuration TLV" is carried in 302 the LSP_ATTRIBUTES object in Path and Resv messages. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type (2) (IANA) | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | OAM Type | Reserved | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 ~ sub-TLVs ~ 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Type: indicates the "OAM Configuration TLV" (2) (IANA to assign). 318 OAM Type: one octet that specifies the technology specific OAM Type. 319 If the requested OAM Type is not supported, an error must be 320 generated: "OAM Problem/Unsupported OAM Type". 322 This document defines a new OAM Type: "MPLS OAM" (suggested value 2, 323 IANA to assign) from the "RSVP-TE OAM Configuration Registry". The 324 "MPLS OAM" type is set to request the establishment of OAM functions 325 for MPLS-TP LSPs. The specific OAM functions are specified in the 326 "Function Flags" sub-TLV as depicted in [OAM-CONF-FWK]. 328 The receiving edge LSR when the MPLS-TP OAM Type is requested should 329 check which OAM Function Flags are set in the "Function Flags TLV" 330 (also defined in [OAM-CONF-FWK]) and look for the corresponding 331 technology specific configuration TLVs. 333 Additional corresponding sub-TLVs are as follows: 335 - "BFD Configuration sub-TLV", which MUST be included if the CC 336 and/or the CV OAM Function flag is set. This sub-TLV MUST carry a 337 "BFD Local Discriminator sub-TLV" and a "Timer Negotiation 338 Parameters sub-TLV" if the N flag is cleared. If the I flag is 339 set, the "BFD Authentication sub-TLV" may be included. 341 - "MPLS OAM PM Loss sub-TLV" within the "Performance Monitoring 342 sub-TLV", which MAY be included if the PM/Loss OAM Function flag 343 is set. If the "MPLS OAM PM Loss sub-TLV" is not included, 344 default configuration values are used. Such sub-TLV MAY also be 345 included in case the Throughput function flag is set and there is 346 the need to specify measurement interval different from the 347 default ones. In fact the throughput measurement make use of the 348 same tool as the loss measurement, hence the same TLV is used. 350 - "MPLS OAM PM Delay sub-TLV" within the "Performance Monitoring 351 sub-TLV", which MAY be included if the PM/Delay OAM Function flag 352 is set. If the "MPLS OAM PM Delay sub-TLV" is not included, 353 default configuration values are used. 355 - "MPLS OAM FMS sub-TLV", which MAY be included if the FMS OAM 356 Function flag is set. If the "MPLS OAM FMS sub-TLV" is not 357 included, default configuration values are used. 359 Moreover, if the CV or CC flag is set, the CC flag MUST be set as 360 well. The format of an MPLS-TP CV/CC message is shown in [BFD-CCCV] 361 and it requires, together with the BFD control packet information, 362 the "Unique MEP-ID of source of BFD packet". [MPLS-TP-IDENTIF] 363 defines the composition of such identifier as: 365 <"Unique MEP-ID of source of BFD packet"> ::= 366 368 Note that support of ITU IDs is out-of-scope. 370 GMPLS signaling [RFC3473] uses a 5-tuple to uniquely identify an LSP 371 within an operator's network. This tuple is composed of a Tunnel 372 Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender 373 Address and (GMPLS) LSP_ID. 375 Hence, the following mapping is used without the need of redefining a 376 new TLV for MPLS-TP proactive CV purpose. 378 - Tunnel ID = src_tunnel_num 380 - Tunnel Sender Address = src_node_id 382 - LSP ID = LSP_Num 384 "Tunnel ID" and "Tunnel Sender Address" are included in the "SESSION" 385 object [RFC3209], which is mandatory in both Path and Resv messages. 387 "LSP ID" will be the same on both directions and it is included in 388 the "SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path 389 messages. 391 [Author's note: the same "Unique MEP-ID of source" will be likely 392 required for Performance monitoring purposes. This need to be agreed 393 with [RFC6374] authors.] 395 3.3. BFD Configuration sub-TLV 397 The "BFD Configuration sub-TLV" (depicted below) is defined for BFD 398 OAM specific configuration parameters. The "BFD Configuration sub- 399 TLV" is carried as a sub-TLV of the "OAM Configuration TLV". 401 This TLV accommodates generic BFD OAM information and carries sub- 402 TLVs. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | BFD Conf. Type (3) (IANA) | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |Vers.| PHB |N|S|I|G|U|B| Reserved (set to all 0s) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 ~ sub-TLVs ~ 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to 417 define). 419 Length: indicates the total length including sub-TLVs. 421 Version: identifies the BFD protocol version. If a node does not 422 support a specific BFD version an error must be generated: "OAM 423 Problem/Unsupported OAM Version". 425 PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic 426 continuity monitoring messages. 428 BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD 429 Control Messages is enabled, when cleared it is disabled. 431 Symmetric session (S): If set the BFD session MUST use symmetric 432 timing values. 434 Integrity (I): If set BFD Authentication MUST be enabled. If the 435 "BFD Configuration sub-TLV" does not include a "BFD Authentication 436 sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre- 437 shared key (all 0s). 439 Encapsulation Capability (G): if set, it shows the capability of 440 encapsulating BFD messages into G-Ach channel. If both the G bit and 441 U bit are set, configuration gives precedence to the G bit. 443 Encapsulation Capability (U): if set, it shows the capability of 444 encapsulating BFD messages into UDP packets. If both the G bit and U 445 bit are set, configuration gives precedence to the G bit. 447 Bidirectional (B): if set, it configures BFD in the Bidirectional 448 mode. If it is not set it configures BFD in unidirectional mode. In 449 the second case, the source node does not expect any Discriminator 450 values back from the destination node. 452 Reserved: Reserved for future specification and set to 0 on 453 transmission and ignored when received. 455 The "BFD Configuration sub-TLV" MUST include the following sub-TLVs 456 in the Path message: 458 - "Local Discriminator sub-TLV"; 460 - "Negotiation Timer Parameters sub-TLV" if the N flag is cleared. 462 The "BFD Configuration sub-TLV" MUST include the following sub-TLVs 463 in the Resv message: 465 - "Local Discriminator sub-TLV;" 467 - "Negotiation Timer Parameters sub-TLV" if: 469 - the N and S flags are cleared, or if: 471 - the N flag is cleared and the S flag is set, and the 472 Negotiation Timer Parameters sub-TLV received by the egress 473 contains unsupported values. In this case an updated 474 Negotiation Timer Parameters sub-TLV, containing values 475 supported by the egress node, is returned to the ingress. 477 3.3.1. Local Discriminator sub-TLV 479 The "Local Discriminator sub-TLV" is carried as a sub-TLV of the "BFD 480 Configuration sub-TLV" and is depicted below. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Lcl. Discr. Type (1) (IANA) | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Local Discriminator | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Type: indicates a new type, the Local Discriminator sub-TLV (1) (IANA 491 to define). 493 Length: indicates the TLV total length in octets. (8) 495 Local Discriminator: A unique, nonzero discriminator value generated 496 by the transmitting system and referring to itself, used to 497 demultiplex multiple BFD sessions between the same pair of systems. 499 3.3.2. Negotiation Timer Parameters sub-TLV 501 The "Negotiation Timer Parameters sub-TLV" is carried as a sub-TLV of 502 the "BFD Configuration sub-TLV" and is depicted below. 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 | Timer Neg. Type (2) (IANA) | Length | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Acceptable Min. Asynchronous TX interval | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Acceptable Min. Asynchronous RX interval | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Required Echo TX Interval | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Type: indicates a new type, the "Negotiation Timer Parameters sub- 517 TLV" (IANA to define). 519 Length: indicates the TLV total length in octets. (16) 521 Acceptable Min. Asynchronous TX interval: in case of S (symmetric) 522 flag set in the "BFD Configuration sub-TLV", it expresses the desired 523 time interval (in microseconds) at which the ingress LER intends to 524 both transmit and receive BFD periodic control packets. If the 525 receiving edge LSR can not support such value, it can reply with an 526 interval greater than the one proposed. 528 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 529 TLV", this field expresses the desired time interval (in 530 microseconds) at which a edge LSR intends to transmit BFD periodic 531 control packets in its transmitting direction. 533 Acceptable Min. Asynchronous RX interval: in case of S (symmetric) 534 flag set in the "BFD Configuration sub-TLV", this field MUST be equal 535 to "Acceptable Min. Asynchronous TX interval" and has no additional 536 meaning respect to the one described for "Acceptable Min. 537 Asynchronous TX interval". 539 In case of S (symmetric) flag cleared in the "BFD Configuration sub- 540 TLV", it expresses the minimum time interval (in microseconds) at 541 which edge LSRs can receive BFD periodic control packets. In case 542 this value is greater than the "Acceptable Min. Asynchronous TX 543 interval" received from the other edge LSR, such edge LSR MUST adopt 544 the interval expressed in this "Acceptable Min. Asynchronous RX 545 interval". 547 Required Echo TX Interval: the minimum interval (in microseconds) 548 between received BFD Echo packets that this system is capable of 549 supporting, less any jitter applied by the sender as described in 550 [RFC5880] sect. 6.8.9. This value is also an indication for the 551 receiving system of the minimum interval between transmitted BFD Echo 552 packets. If this value is zero, the transmitting system does not 553 support the receipt of BFD Echo packets. If the receiving system can 554 not support this value an error MUST be generated "Unsupported BFD TX 555 rate interval". 557 3.3.3. BFD Authentication sub-TLV 559 The "BFD Authentication sub-TLV" is carried as a sub-TLV of the "BFD 560 Configuration sub-TLV" and is depicted below. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | BFD Auth. Type (3) (IANA) | Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Auth Type | Auth Key ID | Reserved (0s) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Type: indicates a new type, the "BFD Authentication sub-TLV" (IANA to 571 define). 573 Length: indicates the TLV total length in octets. (8) 575 Auth Type: indicates which type of authentication to use. The same 576 values as are defined in section 4.1 of [RFC5880] are used. 578 Auth Key ID: indicates which authentication key or password 579 (depending on Auth Type) should be used. How the key exchange is 580 performed is out of scope of this document. 582 Reserved: Reserved for future specification and set to 0 on 583 transmission and ignored when received. 585 3.4. 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 In case the values need to be different than the default ones the 592 "Performance Monitoring sub-TLV", "MPLS OAM PM Loss sub-TLV" MAY 593 include the following sub-TLVs: 595 - "MPLS OAM PM Loss sub-TLV" if the L flag is set in the "OAM 596 functions TLV"; 597 - "MPLS OAM PM Delay sub-TLV" if the D flag is set in the "OAM 598 functions TLV"; 600 The "Performance Monitoring sub-TLV" depicted below is carried as a 601 sub-TLV of the "OAM Functions TLV". 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Perf Monitoring Type(4) (IANA)| Length | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |D|L|J|Y|K|C| Reserved (set to all 0s) | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 ~ sub-TLVs ~ 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Length: indicates the TLV total length in octets. 617 Configuration Flags, for the specific function description please 618 refer to [RFC6374]: 620 - D: Delay inferred/direct (0=INFERRED, 1=DIRECT) 622 - L: Loss inferred/direct (0=INFERRED, 1=DIRECT) 624 - J: Delay variation/jitter (1=ACTIVE, 0=NOT ACTIVE) 626 - Y: Dyadic (1=ACTIVE, 0=NOT ACTIVE) 628 - K: Loopback (1=ACTIVE, 0=NOT ACTIVE) 630 - C: Combined (1=ACTIVE, 0=NOT ACTIVE) 632 Reserved: Reserved for future specification and set to 0 on 633 transmission and ignored when received. 635 3.4.1. MPLS OAM PM Loss sub-TLV 637 The "MPLS OAM PM Loss sub-TLV" depicted below is carried as a sub-TLV 638 of the "Performance Monitoring sub-TLV". 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | PM Loss Type (1) (IANA) | Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | OTF |T|B| Reserved (set to all 0s) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Measurement Interval | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Test Interval | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Loss Threshold | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Type: indicates a new type, the "MPLS OAM PM Loss sub-TLV" (IANA to 655 define, suggested value 1). 657 Length: indicates the length of the parameters in octets (20). 659 OTF: Origin Timestamp Format of the Origin Timestamp field described 660 in [RFC6374]. By default it is set to IEEE 1588 version 1. 662 Configuration Flags, please refer to [RFC6374] for further details: 664 - T: Traffic-class-specific measurement indicator. Set to 1 when 665 the measurement operation is scoped to packets of a particular 666 traffic class (DSCP value), and 0 otherwise. When set to 1, the 667 DS field of the message indicates the measured traffic class. By 668 default it is set to 1. 670 - B: Octet (byte) count. When set to 1, indicates that the 671 Counter 1-4 fields represent octet counts. When set to 0, 672 indicates that the Counter 1-4 fields represent packet counts. By 673 default it is set to 0. 675 Reserved: Reserved for future specification and set to 0 on 676 transmission and ignored when received. 678 Measurement Interval: the time interval (in microseconds) at which 679 Loss Measurement query messages MUST be sent on both directions. If 680 the edge LSR receiving the Path message can not support such value, 681 it can reply back with a higher interval. By default it is set to 682 (TBD). 684 Test Interval: test messages interval as described in [RFC6374]. By 685 default it is set to (TBD). 687 Loss Threshold: the threshold value of lost packets over which 688 protections MUST be triggered. By default it is set to (TBD). 690 3.4.2. MPLS OAM PM Delay sub-TLV 692 The "MPLS OAM PM Delay sub-TLV" depicted below is carried as a sub- 693 TLV of the "OAM Functions TLV". 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | PM Delay Type (2) (IANA) | Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | OTF |T|B| Reserved (set to all 0s) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Measurement Interval | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Test Interval | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Delay Threshold | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Type: indicates a new type, the "MPLS OAM PM Loss sub-TLV" (IANA to 710 define, suggested value 1). 712 Length: indicates the length of the parameters in octets (20). 714 OTF: Origin Timestamp Format of the Origin Timestamp field described 715 in [RFC6374]. By default it is set to IEEE 1588 version 1. 717 Configuration Flags, please refer to [RFC6374] for further details: 719 - T: Traffic-class-specific measurement indicator. Set to 1 when 720 the measurement operation is scoped to packets of a particular 721 traffic class (DSCP value), and 0 otherwise. When set to 1, the 722 DS field of the message indicates the measured traffic class. By 723 default it is set to 1. 725 - B: Octet (byte) count. When set to 1, indicates that the 726 Counter 1-4 fields represent octet counts. When set to 0, 727 indicates that the Counter 1-4 fields represent packet counts. By 728 default it is set to 0. 730 Reserved: Reserved for future specification and set to 0 on 731 transmission and ignored when received. 733 Measurement Interval: the time interval (in microseconds) at which 734 Delay Measurement query messages MUST be sent on both directions. If 735 the edge LSR receiving the Path message can not support such value, 736 it can reply back with a higher interval. By default it is set to 737 (TBD). 739 Test Interval: test messages interval as described in [RFC6374]. By 740 default it is set to (TBD). 742 Delay Threshold: the threshold value of measured delay (in 743 microseconds) over which protections MUST be triggered. By default 744 it is set to (TBD). 746 3.5. MPLS OAM FMS sub-TLV 748 The "MPLS OAM FMS sub-TLV" depicted below is carried as a sub-TLV of 749 the "OAM Configuration sub-TLV". When both working and protection 750 paths are signaled, both LSPs SHOULD be signaled with identical 751 settings of the E flag, T flag, and the refresh timer. 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | MPLS OAM FMS Type (5) (IANA) | Length | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 |E|S|T| Reserved (set to all 0s)| Refresh Timer | PHB | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Type: indicates a new type, the "MPLS OAM FMS sub-TLV" (IANA to 762 define). 764 Length: indicates the TLV total length in octets. (8) 766 FMS Signal Flags are used to enable the FMS signals at end point MEPs 767 and the Server MEPs of the links over which the LSP is forwarded. In 768 this document only the S flag pertains to Server MEPs. 770 The following flags are defined: 772 - E: Enable Alarm Indication Signal (AIS) and Locked Report (LKR) 773 signalling as described in [MPLS-FMS]. Default value is 1 774 (enabled). 776 - S: Indicate to a server MEP that its should transmit AIS and LKR 777 signals on the client LSP. Default value is 0 (disabled). 779 - T: Set timer value, enabled the configuration of a specific 780 timer value. Default value is 0 (disabled). 782 - Remaining bits: Reserved for future specification and set to 0. 784 Refresh Timer: indicates the refresh timer of fault indication 785 messages. If the edge LSR receiving the Path message can not support 786 such value, it can reply back with a higher interval. 788 - PHB: identifies the per-hop behavior of packets with fault 789 management information. 791 4. IANA Considerations 793 This document specifies the following new TLV types: 795 - "BFD Configuration" type: 3; 797 - "Performance Monitoring" type: 4; 799 - "MPLS OAM FMS" type: 5. 801 sub-TLV types to be carried in the "BFD Configuration sub-TLV": 803 - "Local Discriminator" sub-TLV type: 1; 805 - "Negotiation Timer Parameters" sub-TLV type: 2. 807 - "BFD Authentication" sub-TLV type: 3. 809 sub-TLV types to be carried in the "BFD Configuration sub-TLV": 811 - "MPLS OAM PM Loss" type: 1; 813 - "MPLS OAM PM Delay" type: 2; 815 5. BFD OAM configuration errors 817 In addition to error values specified in [OAM-CONF-FWK] and [ETH-OAM] 818 this document defines the following values for the "OAM Problem" 819 Error Code: 821 - "MPLS OAM Unsupported Functionality"; 823 - "OAM Problem/Unsupported TX rate interval"; 825 - "OAM Problem/Unsupported RX rate interval"; 826 - "OAM Problem/Unsupported unsupported Authentication Type"; 828 - "OAM Problem, mismatch of Authentication Key ID ". 830 6. Acknowledgements 832 The authors would like to thank David Allan, Lou Berger, Annamaria 833 Fulignoli, Eric Gray, Andras Kern, David Jocha and David Sinicrope 834 for their useful comments. 836 7. Security Considerations 838 The signaling of OAM related parameters and the automatic 839 establishment of OAM entities introduces additional security 840 considerations to those discussed in [RFC3473]. In particular, a 841 network element could be overloaded if an attacker were to request 842 high frequency liveliness monitoring of a large number of LSPs, 843 targeting a single network element. 845 Security aspects will be covered in more detailed in subsequent 846 versions of this document. 848 8. References 850 8.1. Normative References 852 [MPLS-FMS] 853 Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., 854 and D. Ward, "MPLS Fault Management OAM", 2009, 855 . 857 [MPLS-TP-IDENTIF] 858 Bocci, M., Swallow, G., and E. Gray, "MPLS-TP 859 Identifiers", 2010, . 861 [OAM-CONF-FWK] 862 Takacs, A., Fedyk, D., and J. van He, "OAM Configuration 863 Framework for GMPLS RSVP-TE", 2009, 864 . 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, March 1997. 869 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 870 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 871 Tunnels", RFC 3209, December 2001. 873 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 874 (GMPLS) Signaling Functional Description", RFC 3471, 875 January 2003. 877 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 878 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 879 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 881 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 882 Associated Channel", RFC 5586, June 2009. 884 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 885 and S. Ueno, "Requirements of an MPLS Transport Profile", 886 RFC 5654, September 2009. 888 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 889 Operations, Administration, and Maintenance (OAM) in MPLS 890 Transport Networks", RFC 5860, May 2010. 892 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 893 (BFD)", RFC 5880, June 2010. 895 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 896 "Bidirectional Forwarding Detection (BFD) for MPLS Label 897 Switched Paths (LSPs)", RFC 5884, June 2010. 899 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 900 Measurement for MPLS Networks", RFC 6374, September 2011. 902 [RFC6375] Frost, D. and S. Bryant, "A Packet Loss and Delay 903 Measurement Profile for MPLS-Based Transport Networks", 904 RFC 6375, September 2011. 906 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive 907 Connectivity Verification, Continuity Check, and Remote 908 Defect Indication for the MPLS Transport Profile", 909 RFC 6428, November 2011. 911 8.2. Informative References 913 [BFD-CCCV] 914 Allan, D., Swallow, G., and J. Drake, "Proactive 915 Connectivity Verification, Continuity Check and Remote 916 Defect indication for MPLS Transport Profile", 2010, 917 . 919 [BFD-Ping] 920 Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher, 921 N., and Y. Weingarten, "LSP Ping and BFD encapsulation 922 over ACH", 2010, 923 . 925 [ETH-OAM] Takacs, A., Gero, B., Fedyk, D., Mohan, D., and D. Long, 926 "GMPLS RSVP-TE Extensions for Ethernet OAM", 2009, 927 . 929 [LSP-PING-CONF] 930 Bellagamba, E., Andersson, L., Ward, D., and P. 931 Skoldstrom, "Configuration of pro-active MPLS-TP 932 Operations, Administration, and Maintenance (OAM) 933 Functions Using LSP Ping", 2010, 934 . 936 [MPLS-TP-OAM-Analysis] 937 Sprecher, N., Weingarten, Y., and E. Bellagamba, "MPLS-TP 938 OAM Analysis", 2011, . 940 [MPLS-TP-OAM-FWK] 941 Bocci, M. and D. Allan, "Operations, Administration and 942 Maintenance Framework for MPLS-based Transport Networks", 943 2010, . 945 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 946 Label Switched (MPLS) Data Plane Failures", RFC 4379, 947 February 2006. 949 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 950 Heron, "Pseudowire Setup and Maintenance Using the Label 951 Distribution Protocol (LDP)", RFC 4447, April 2006. 953 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 954 Berger, "A Framework for MPLS in Transport Networks", 955 RFC 5921, July 2010. 957 Authors' Addresses 959 Elisa Bellagamba (editor) 960 Ericsson 961 Torshamnsgatan 48 962 Kista, 164 40 963 Sweden 965 Email: elisa.bellagamba@ericsson.com 967 Loa Andersson (editor) 968 Ericsson 969 Torshamnsgatan 48 970 Kista, 164 40 971 Sweden 973 Phone: 974 Email: loa.andersson@ericsson.com 976 Pontus Skoldstrom (editor) 977 Acreo AB 978 Electrum 236 979 Kista, 164 40 980 Sweden 982 Phone: +46 8 6327731 983 Email: pontus.skoldstrom@acreo.se 985 Dave Ward 986 Juniper 988 Phone: 989 Email: dward@juniper.net 991 Attila Takacs 992 Ericsson 993 1. Laborc u. 994 Budapest, 995 HUNGARY 997 Phone: 998 Email: attila.takacs@ericsson.com