idnits 2.17.1 draft-ietf-pim-source-discovery-bsr-03.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A router that receives an SG message should parse the message and store the SG mappings with a holdtimer started with the advertised holdtime for that group. If there are directly connected receivers for that group this router should send PIM (S,G) joins for all the SG mappings advertised in the message. The SG mappings are kept alive for as long as the holdtimer for the source is running. Once the holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to remove itself from the tree. Note that a holdtime of 0 has a special meaning. It is to be treated as if the source just expired, causing a prune to be sent and state to be removed. Source information MUST not be removed due to it being omitted in a message. For instance, if there are a large number of sources for a group, there may be multiple SG messages for the same group, each message containing a different list of sources. -- The document date (July 1, 2015) is 3222 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands 3 Internet-Draft S. Venaas 4 Intended status: Experimental Cisco Systems, Inc. 5 Expires: January 2, 2016 M. Brig 6 Aegis BMD Program Office 7 A. Jonasson 8 Swedish Defence Material Administration (FMV) 9 July 1, 2015 11 PIM flooding mechanism and source discovery 12 draft-ietf-pim-source-discovery-bsr-03 14 Abstract 16 PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to 17 forward multicast packets to Last Hop Routers (LHR). After the first 18 packet is received by the LHR, the source of the multicast stream is 19 learned and the Shortest Path Tree (SPT) can be joined. This draft 20 proposes a solution to support PIM Sparse Mode (SM) without the need 21 for PIM registers, RPs or shared trees. Multicast source information 22 is flooded throughout the multicast domain using a new generic PIM 23 flooding mechanism. This mechanism is defined in this document, and 24 is modeled after the PIM Bootstrap Router protocol. By removing the 25 need for RPs and shared trees, the PIM-SM procedures are simplified, 26 improving router operations, management and making the protocol more 27 robust. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 2, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Conventions used in this document . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Testing and deployment experiences . . . . . . . . . . . . . 3 67 3. A generic PIM flooding mechanism . . . . . . . . . . . . . . 4 68 3.1. PFP message format . . . . . . . . . . . . . . . . . . . 4 69 3.2. Processing PFP messages . . . . . . . . . . . . . . . . . 6 70 3.2.1. Initial checks . . . . . . . . . . . . . . . . . . . 6 71 3.2.2. Processing messages with known PFP type . . . . . . . 6 72 3.2.3. Processing messages with unknown PFP type . . . . . . 6 73 4. Distributing Source to Group Mappings . . . . . . . . . . . . 7 74 4.1. Group Source Holdtime TLV . . . . . . . . . . . . . . . . 7 75 4.2. Originating SG messages . . . . . . . . . . . . . . . . . 8 76 4.3. Processing SG messages . . . . . . . . . . . . . . . . . 8 77 4.4. The first packets and bursty sources . . . . . . . . . . 9 78 4.5. Resiliency to network partitioning . . . . . . . . . . . 10 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 8.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to 90 forward multicast packets to Last Hop Routers (LHR). After the first 91 packet is received by the LHR, the source of the multicast stream is 92 learned and the Shortest Path Tree (SPT) can be joined. This draft 93 proposes a solution to support PIM Sparse Mode (SM) without the need 94 for PIM registers, RPs or shared trees. Multicast source information 95 is flooded throughout the multicast domain using a new generic PIM 96 flooding mechanism. This mechanism is defined in this document, and 97 is modeled after the Bootstrap Router protocol [RFC5059]. By 98 removing the need for RPs and shared trees, the PIM-SM procedures are 99 simplified, improving router operations, management and making the 100 protocol more robust. 102 1.1. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 1.2. Terminology 110 RP: Rendezvous Point. 112 BSR: Bootstrap Router. 114 RPF: Reverse Path Forwarding. 116 SPT: Shortest Path Tree. 118 FHR: First Hop Router, directly connected to the source. 120 LHR: Last Hop Router, directly connected to the receiver. 122 SG Mapping: Multicast source to group mapping. 124 SG Message: A PIM message containing SG Mappings. 126 2. Testing and deployment experiences 128 A prototype of this specification has been implemented and there has 129 been some limited testing in the field. The prototype was tested in 130 a network with low bandwidth radio links. In this network with 131 frequent topology changes and link or router failures PIM-SM with RP 132 election is found to be too slow. With PIM-DM issues were observed 133 with new multicast sources starving low bandwidth links even when 134 there are no receivers, in some cases such that there were no 135 bandwidth left for prune message. For the tests, all routers were 136 configured to send PFP-SA for directly connected source and to cache 137 received announcements. Applications such as SIP with multicast 138 subscriber discovery, multicast voice conferencing, position tracking 139 and NTP were successfully tested. The tests went quite well. 140 Packets were rerouted as needed and there were no unnecessary 141 forwarding of packets. Ease of configuration was seen as a plus. 143 3. A generic PIM flooding mechanism 145 The Bootstrap Router protocol (BSR) [RFC5059] is a commonly used 146 protocol for distributing dynamic Group to RP mappings in PIM. It is 147 responsible for flooding information about such mappings throughout a 148 PIM domain, so that all routers in the domain can have the same 149 information. BSR as defined, is only able to distribute Group to RP 150 mappings. We are defining a more generic mechanism that can flood 151 any kind of information throughout a PIM domain. It is not 152 necessarily a domain though, it depends on the administrative 153 boundaries being configured. The forwarding rules are identical to 154 BSR, except that there is no BSR election and that one can control 155 whether routers should forward messages of unsupported types. For 156 some types of information it is quite useful that it can be 157 distributed without all routers having to support the particular 158 type, while there may also be types where it is necessary for every 159 single router to support it. The protocol includes an originator 160 address which is used for RPF checking to restrict the flooding, just 161 like BSR. Just like BSR it is also sent hop by hop. Note that there 162 is no built in election mechanism as in BSR, so there can be multiple 163 originators. It is still possible to add such an election mechanism 164 on a type by type bases if this protocol is used in scenarios where 165 this is desirable. We include a type field, which can allow 166 boundaries to be defined, and election to take place, independently 167 per type. We call this protocol the PIM Flooding Protocol (PFP). 169 3.1. PFP message format 170 0 1 2 3 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |PIM Ver| Type |N| Reserved | Checksum | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Originator Address (Encoded-Unicast format) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | PFP Type | Reserved |U| 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type 1 | Length 1 | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Value 1 | 182 | . | 183 | . | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | . | 186 | . | 187 | Type n | Length n | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Value n | 190 | . | 191 | . | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 PIM Version: Reserved, Checksum Described in [RFC4601]. 196 Type: PIM Message Type. Value (pending IANA) for a PFP message. 198 [N]o-Forward bit: When set, this bit means that the PFP message is 199 not to be forwarded. 201 Originator Address: The address of the router that originated the 202 message. This can be any address assigned to this router, but 203 MUST be routable in the domain to allow successful forwarding 204 (just like BSR address). The format for this address is given in 205 the Encoded-Unicast address in [RFC4601]. 207 PFP Type: There may be different sub protocols or different uses 208 for this generic protocol. The PFP Type specifies which sub 209 protocol it is used for. 211 [U]nknown-No-Forwarding bit: Some sub protocols may require that 212 each router do some processing of the contents and not simply 213 forwarding. This bit controls how a router should treat an 214 unknown PFP Type. When set, a router MUST NOT forward the message 215 when the PFP Type is unknown. When clear, a router MUST forward 216 the message when possible. If the PFP Type is known, then the 217 specification of that type will specify how to handle the message, 218 including whether it should be forwarded. 220 Type 1..n: A message contains one or more TLVs, in this case n 221 TLVs. The Type specifies what kind of information is in the 222 Value. Note that the Type space is shared between all PFP types. 223 Not all types make sense for all PFP types though. 225 Length 1..n: The length of the the value field. 227 Value 1..n: The value associated with the type and of the specified 228 length. 230 3.2. Processing PFP messages 232 A router that receives an PFP message must perform the initial checks 233 specified here. If it passes, the contents is processed according to 234 the PFP type if known. If the type is unknown it may still be 235 forwarded. 237 3.2.1. Initial checks 239 The initial checks performed are largely similar to what is done for 240 BSR messages. The message MUST be from a directly connected neighbor 241 for which we have active Hello state. It MUST have been sent to the 242 ALL-PIM-ROUTERS group, and unless No-Forward is set, it MUST have 243 been sent by the RPF neighbor towards the router that originated the 244 message; or, if it is a No-Forward BSM, we must have restarted within 245 60 seconds. 247 3.2.2. Processing messages with known PFP type 249 If the PFP type is known, as in supported by the implementation, the 250 processing and potential forwarding is done according to the 251 specification for that PFP type. If the PFP type specification does 252 not specify any particular forwarding rules, the message is forwarded 253 out of all interfaces with PIM neighbors (including the interface it 254 is received on). 256 3.2.3. Processing messages with unknown PFP type 258 If the PFP type is unknown, the message MUST be dropped if the 259 Unknown-No-Forwarding bit is set. If the bit is not set, the message 260 is forwarded out of all interfaces with PIM neighbors (including the 261 interface it is received on). 263 4. Distributing Source to Group Mappings 265 We want to provide information about active multicast sources 266 throughout a PIM domain by making use of the generic flooding 267 mechanism defined in the previous section. We request PFP Type 0 to 268 be assigned for this purpose. We call a message with PFP Type 0 an 269 SG Message. We also define a PFP TLV which we request to be type 0. 270 How this TLV is used with PFP Type 0 is defined in the next section. 271 Other PFP Types may specify the use of this TLV for other purposes. 272 For PFP Type 0 the U-bit MUST NOT be set. This means that routers 273 not supporting PFP Type 0 would still forward the message. 275 4.1. Group Source Holdtime TLV 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type = 0 | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Group Address (Encoded-Group format) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Src Count | Src Holdtime | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Src Address 1 (Encoded-Unicast format) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Src Address 2 (Encoded-Unicast format) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | . | 291 | . | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Src Address m (Encoded-Unicast format) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Type: This TLV has type 0. 298 Length: The length of the value. 300 Group Address: The group we are announcing sources for. The format 301 for this address is given in the Encoded-Group format in 302 [RFC4601]. 304 Src Count: How many unicast encoded sources address encodings 305 follow. 307 Src Holdtime: The Holdtime (in seconds) for the corresponding 308 source(s). 310 Src Address: The source address for the corresponding group. The 311 format for these addresses is given in the Encoded-Unicast address 312 in [RFC4601]. 314 4.2. Originating SG messages 316 An SG Mesage, that is a PFP message of Type 0, may contain one or 317 more Group Source Holdtime TLVs. This is used to flood information 318 about active multicast sources. Each FHR that is directly connected 319 to an active multicast source originates SG BSR messages. How a 320 multicast router discovers the source of the multicast packet and 321 when it considers itself the FHR follows the same procedures as the 322 registering process described in [RFC4601]. After it is decided that 323 a register needs to be sent, the SG is not registered via the PIM SM 324 register procedures, but the SG mapping is included in an SG message. 325 Note, only the SG mapping is distributed in the message, not the 326 entire packet as would have been done with a PIM register. The 327 router originating the SG messages includes one of its own addresses 328 in the originator field. Note that this address must be routeable 329 due to RPF checking. The SG messages are periodically sent for as 330 long as the multicast source is active, similar to how PIM registers 331 are periodically sent. The default announcement period is 60 332 seconds, which means that as long as the source is active, it is 333 included in an SG message originated every 60 seconds. The holdtime 334 for the source is by default 210 seconds. Other values can be 335 configured, but the holdtime must be larger than the announcement 336 period. It is RECOMMENDED to be 3.5 times the announcement period. 337 Note that as a special case a source MAY be announced with a holdtime 338 of 0 to indicate that the source is no longer active. 340 4.3. Processing SG messages 342 A router that receives an SG message should parse the message and 343 store the SG mappings with a holdtimer started with the advertised 344 holdtime for that group. If there are directly connected receivers 345 for that group this router should send PIM (S,G) joins for all the SG 346 mappings advertised in the message. The SG mappings are kept alive 347 for as long as the holdtimer for the source is running. Once the 348 holdtimer expires a PIM router SHOULD send a PIM (S,G) prune to 349 remove itself from the tree. Note that a holdtime of 0 has a special 350 meaning. It is to be treated as if the source just expired, causing 351 a prune to be sent and state to be removed. Source information MUST 352 not be removed due to it being omitted in a message. For instance, 353 if there are a large number of sources for a group, there may be 354 multiple SG messages for the same group, each message containing a 355 different list of sources. 357 4.4. The first packets and bursty sources 359 The PIM register procedure is designed to deliver Multicast packets 360 to the RP in the absence of a native SPT tree from the RP to the 361 source. The register packets received on the RP are decapsulated and 362 forwarded down the shared tree to the LHRs. As soon as an SPT tree 363 is built, multicast packets would flow natively over the SPT to the 364 RP or LHR and the register process would stop. The PIM register 365 process ensures packet delivery until an SPT tree is in place 366 reaching the FHR. If the packets were not unicast encapsulated to 367 the RP they would be dropped by the FHR until the SPT is setup. This 368 functionality is important for applications where the initial 369 packet(s) must be received for the application to work correctly. 370 Another reason would be for bursty sources. If the application sends 371 out a multicast packet every 4 minutes (or longer), the SPT is torn 372 down (typically after 3:30 minutes of inactivity) before the next 373 packet is forwarded down the tree. This will cause no multicast 374 packet to ever be forwarded. A well behaved application should 375 really be able to deal with packet loss since IP is a best effort 376 based packet delivery system. But in reality this is not always the 377 case. 379 With the procedures proposed in this draft the packet(s) received by 380 the FHR will be dropped until the LHR has learned about the source 381 and the SPT tree is built. That means for bursty sources or 382 applications sensitive for the delivery of the first packet this 383 proposal would not be very applicable. This proposal is mostly 384 useful for applications that don't have strong dependency on the 385 initial packet(s) and have a fairly constant data rate, like video 386 distribution for example. For applications with strong dependency on 387 the initial packet(s) we recommend using PIM Bidir [RFC5015] or SSM 388 [RFC4607]. The protocol operations are much simpler compared to PIM 389 SM, it will cause less churn in the network and both guarantee best 390 effort delivery for the initial packet(s). 392 Another solution to address the problems described above is 393 documented in [I-D.ietf-magma-msnip]. This proposal allows for a 394 host to tell the FHR its willingness to act as Source for a certain 395 Group before sending the data packets. LHRs have time to join the 396 SPT tree before the host starts sending which would avoid packet 397 loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be 398 advertised directly in SG messages, allowing a very nice integration 399 of both proposals. The life time of the SPT is not driven by the 400 liveliness of Multicast data packets (which is the case with PIM SM), 401 but by the announcements driven via [I-D.ietf-magma-msnip]. This 402 will also prevent packet loss due to bursty sources. 404 4.5. Resiliency to network partitioning 406 In a PIM SM deployment where the network becomes partitioned, due to 407 link or node failure, it is possible that the RP becomes unreachable 408 to a certain part of the network. New sources that become active in 409 that partition will not be able to register to the RP and receivers 410 within that partition are not able to receive the traffic. Ideally 411 you would want to have a candidate RP in each partition, but you 412 never know in advance which routers will form a partitioned network. 413 In order to be fully resilient, each router in the network may end up 414 being a candidate RP. This would increase the operational complexity 415 of the network. 417 The solution described in this document does not suffer from that 418 problem. If a network becomes partitioned and new sources become 419 active, the receivers in that partitioned will receive the SG 420 Mappings and join the source tree. Each partition works 421 independently of the other partition(s) and will continue to have 422 access to sources within that partition. As soon as the network 423 heals, the SG Mappings are re-flooded into the other partition(s) and 424 other receivers can join to the newly learned sources. 426 5. Security Considerations 428 The security considerations are mainly similar to what is documented 429 in [RFC5059]. It may be a concern that rogue devices can inject 430 packets that are flooded throughout a domain. PFP packets SHOULD 431 only be accepted from a PIM neighbor. Deployments may use mechanisms 432 for authenticating PIM neighbors. 434 6. IANA considerations 436 This document requires the assignment of a new PIM Protocol type for 437 the PIM Flooding Protocol (PFP). IANA is also requested to create a 438 registry for PFP Types with type 0 allocated to "Source-Group 439 Message". IANA is also requested to create a registry for PFP TLVs, 440 with type 0 allocated to the "Source Group Holdtime" TLV. The 441 allocation procedures are yet to be determined. 443 7. Acknowledgments 445 The authors would like to thank Arjen Boers for contributing to the 446 initial idea and Yiqun Cai for his comments on the draft. 448 8. References 450 8.1. Normative References 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 456 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 457 Protocol Specification (Revised)", RFC 4601, August 2006. 459 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 460 "Bootstrap Router (BSR) Mechanism for Protocol Independent 461 Multicast (PIM)", RFC 5059, January 2008. 463 8.2. Informative References 465 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 466 IP", RFC 4607, August 2006. 468 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 469 "Bidirectional Protocol Independent Multicast (BIDIR- 470 PIM)", RFC 5015, October 2007. 472 [I-D.ietf-magma-msnip] 473 Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and 474 S. Venaas, "Multicast Source Notification of Interest 475 Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in 476 progress), March 2011. 478 Authors' Addresses 480 IJsbrand Wijnands 481 Cisco Systems, Inc. 482 De kleetlaan 6a 483 Diegem 1831 484 Belgium 486 Email: ice@cisco.com 488 Stig Venaas 489 Cisco Systems, Inc. 490 Tasman Drive 491 San Jose CA 95134 492 USA 494 Email: stig@cisco.com 495 Michael Brig 496 Aegis BMD Program Office 497 17211 Avenue D, Suite 160 498 Dahlgren VA 22448-5148 499 USA 501 Email: michael.brig@mda.mil 503 Anders Jonasson 504 Swedish Defence Material Administration (FMV) 505 Loennvaegen 4 506 Vaexjoe 35243 507 Sweden 509 Email: anders@jomac.se