IETF Meeting Network Requirements

This is an archived webpage. For current information about the IETF administrative arrangements, see the IETF Administration LLC website.
Home About Announcements Committees Documents Members Minutes Budget & Finance Budgets Financial Statements IETF Meeting Financial Statements IETF Meetings Host & Sponsorship Opportunities IAOC Plenary Reports Remote Participation Surveys Venue Selection IETF Trust Legal Legal Requests Legal Request Procedures Operations Appeals Contracts Policies & Procedures Projects Reports Procurement RFIs RFPs	IETF Meeting Network Requirements Date: June 9, 2009 Editor(s): Karen O'Donoghue, Jim Martin, Chris Elliott, Joel Jaeggli Abstract The IETF Meeting Network has become integral to the success of any meeting. Building such a network, which provides service to thousands of heavy users, spread throughout the event venue, with very little time for setup and testing is a dramatic challenge. This document provides a set of requirements, derived from hard won experience, as an aid to anyone involved in designing and deploying future networks. 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. External Connectivity A primary and backup link MUST be provided for redundancy. If technically feasible, these links SHOULD be aggregated or load balanced. The primary link MUST provide at least 45Mb bandwidth in both directions, and SHOULD have at least 100Mb bidirectionally. (Note: Historically, bandwidth utilization peaked at 80Mb and averaged 35Mb. Recent events have peaked at 50 Mbs and averaged in the 25Mb range.) The backup link MUST have 10 Mb bandwidth in both directions and SHOULD have at least 45 Mb bandwidth in both directions. The backup link SHOULD be supplied by a different Internet service provider from the primary link. The primary and backup links SHOULD have physical and logical path diversity. IPv6 MUST be provided (possibly via a tunnel). The transit provided in support of the IETF MUST be capable of providing access to the IPv4 and IPv6 default free zones without the imposition of content filtering (e.g., URL, Site, application, port, or DPI based filtering). The primary link MUST support BGP peering, and the backup link SHOULD support BGP peering. Routing MAY be configured to allow the simultaneous usage of the bandwidth of both the primary and backup links. Access to research networks, like those that are part of Internet 2, MAY be provided on one of the external links. AS Numbers MAY be supplied by the network provider. If not, the network provider MUST use the AS Numbers provided by IETF. The network provider MUST provide at least a /19 of provider independent public IPv4 space or allow the IETF to advertise their own space. The network provider MUST provide at least a /32 of LIR public IPv6 space or allow the IETF to advertise their own space. If providing access space, the network provider MUST provide proper IP address delegation for DNS reverse lookups. 3. Meeting Facility The facility SHOULD have as much physical separation as possible in the meeting room area to improve the RF environment. In addition, the facility SHOULD avoid using airwalls and other partitions with low RF attenuation in the 2.4Mhz spectrum between meeting rooms. The facility SHOULD provide a RF environment in all meeting rooms (as identified by the Secretariat), common gathering spaces around the meeting rooms, the registration area, and the terminal room that has a reasonable noise floor in the 2.4Mhz spectrum. The meeting facility SHOULD have installed network cabling that can be used to deploy the network infrastructure. The meeting facility SHOULD provide the network installation team with 24 hour access to key telecom spaces. The meeting facility MUST provide the network installation team with access to key telecom spaces from one hour prior to the beginning of sessions to one hour after the end of sessions and 9am to 5pm daily during the setup period. All locations for network gear, with the exception of wireless APs, MUST be secure. If wireless will be used for an external link then access to the roof or installed location MUST be provided. The meeting facility MUST have adequate ventilation to support the equipment rooms and the terminal room. The meeting facility MUST have adequate power available to support the equipment required to support the network infrastructure and its users. This may include 110v/220v requirements in technical closets, roof locations, and various public and back-of-the-house areas. The meeting facility The meeting facility SHOULD have UPS power available to support key network infrastructure components, including at least the core routers, core switches, and hardware to maintain the external links. The meeting facility MUST provide sufficient power in all meeting rooms to handle the projected load from users' laptops, using 100% congruency between the projected number of attendees in each meeting room and the number of laptop users and projecting 70 watts of power usage per laptop. 4. Internal Network Wired Ethernet connections (network drops) MUST be provided in all the locations used for meeting room audio distribution for the purposes of audio recording and transmission. Wired network drops MUST be provided to the registration desk. The network SHOULD have separate VLANS for wired (primarily terminal room and audio) and wireless traffic. The network MUST NOT prohibit end-to-end and external connectivity for any traffic (no limiting firewalls or NATs). The network SHOULD have mechanisms for detecting and silencing rogue servers (DHCP, IPv6 RA's, etc) 5. Terminal Room or equivalent Terminal Room or equivalent A terminal room MUST be provided. This terminal room MAY be a single room or distributed sites in reasonable proximity to the meeting rooms. The terminal room MUST provide Ethernet 10/100 connectivity with RJ-45 connectors (approximately 100-150 drops required). (note: this number should be revised based on terminal room usage statistics) The terminal room SHOULD provide a small number of desktop or laptop computers for emergency use by attendees (minimum application requirements are web browsing, word processing, presentation production, and printing capability). The terminal room SHOULD have 24 hour access. This access SHOULD include security, but it MAY not include a 24 hour staffed help desk. The IETF users MUST have access to the terminal room from one hour prior to the beginning of sessions to one hour after the end of sessions. The terminal room MUST provide at least two network connected enterprise class printers. These printers SHOULD have duplex capability. A color printer MAY be provided. The terminal room MUST have a manned help desk from one hour prior to the beginning of sessions to one hour after the end of sessions. The help desk provides technical assistance to attendees, provides one potential interface to the trouble ticket system (see next requirement), and maintains the printers. The network supplier SHOULD provide a trouble ticket system to track attendee network issues. This trouble ticket system SHOULD be accessible to the help desk staff in addition to NOC staff. Power strips MUST be provided in the terminal room. Power strips MAY be provided in common gathering areas (desirable). The terminal room MUST have physical security (guards) during operating hours. 6. Wireless The network MUST provide 802.11b coverage in all meeting rooms (as identified by the Secretariat), common gathering spaces around the meeting rooms, the registration area, and the terminal room. The network SHOULD provide 802.11b coverage in additional common spaces in the meeting venue. The lobby, bar, restaurant, and most commonly used hallways of the primary meeting hotels, SHOULD also be provide 802.11b access. The network SHOULD provide 802.11g in all the spaces identified above. The network SHOULD provide 802.11a coverage in as many of the above identified spaces as possible focusing on the spaces with the highest user density first (e.g. plenary meeting room). The network design MUST anticipate 100% congruency between the projected number of attendees in each meeting room and the number of wireless network users (historical utilization in excess of 1000 simultaneous wireless users has been observed during a plenary session). The network SHOULD provide separate SSIDs for 802.11b and 802.11a networks. The network MUST provide fully open (unsecured) wireless access. The network MAY provide additional secured (WEP, 802.11i, WPA) wireless access. There SHOULD be mechanisms for identifying and silencing rogue Wireless Access Points. 7. Services The network MUST provide redundant DHCPv4 servers. The network SHOULD provide DHCPv6 service. The network MUST provide local redundant DNS servers. The network SHOULD provide NTP. Printers MUST support IPP and SHOULD support LPR and Windows printing. The network MUST provide a SMTP server providing relay services for the IETF network. The network SHOULD provide a full on-site mirror of the RFC and I-D directories. 8. Network Monitoring The network MUST provide sufficient monitoring to ensure adequate network availability and to detect faults before they impact the user experience. The network SHOULD provide some visibility into the state of the network for attendees (e.g. public graphs of network utilization, number of wireless associations, etc.). The network MUST collect data for future use in scaling IETF meeting network requirements. Minimum required metrics include bandwidth utilization (average and peak) for each external connection and user density per AP and radio. The network provider SHOULD provide SNMP read-only access to the network devices to individuals as identified by the Secretariat for network management and planning purposes. 9. Miscellaneous Requirements The network provider SHOULD maintain spares of critical network components on-site. Attendees SHOULD be notified of power connector requirements well in advance of the meeting via both the IETF meeting web page and the IETF- announce mailing list. A document MUST be provided to attendees detailing on-site network configuration information, including wireless configuration details, services available (e.g. printing, SMTP), instructions on how to report network issues (e.g. trouble ticket system interface instructions), etc. Initial versions of this information SHOULD be provided in advance of the meeting. The network provider MUST NOT view the IETF network as an experimental facility at the risk of impacting the IETF attendee experience. (Do not experiment with his/her favorite pet technology.) The network provider SHOULD have attended at least one prior IETF to observe the IETF network deployment and operation. The network provider SHOULD supply the IETF network design to an IETF technical review team for comments. 10. Acknowledgements These requirements are born out of the pain and experience of past hosts and volunteers. Contributors of particular note are (in no particular order): Jim Martin Karen O'Donoghue Chirs Elliott Joel Jaeggli Lucy Lynch Bill "wej' Jensen Chris Liljenstoipe Bill Fenner Hans Kuhn References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Home - Web Site Usage Stats - IETF - IETF Trust - ISOC - RFC Editor - IANA - Store Please send problem reports to: ietf-action@ietf.org.
Last Updated 28 August 2018

Date: June 9, 2009

Editor(s): Karen O'Donoghue, Jim Martin, Chris Elliott, Joel Jaeggli

Abstract

The IETF Meeting Network has become integral to the success of any meeting. Building such a network, which provides service to thousands of heavy users, spread throughout the event venue, with very little time for setup and testing is a dramatic challenge. This document provides a set of requirements, derived from hard won experience, as an aid to anyone involved in designing and deploying future networks.

1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. External Connectivity

A primary and backup link MUST be provided for redundancy. If technically feasible, these links SHOULD be aggregated or load balanced.
The primary link MUST provide at least 45Mb bandwidth in both directions, and SHOULD have at least 100Mb bidirectionally. (Note: Historically, bandwidth utilization peaked at 80Mb and averaged 35Mb.
Recent events have peaked at 50 Mbs and averaged in the 25Mb range.) The backup link MUST have 10 Mb bandwidth in both directions and SHOULD have at least 45 Mb bandwidth in both directions.
The backup link SHOULD be supplied by a different Internet service provider from the primary link.
The primary and backup links SHOULD have physical and logical path diversity.
IPv6 MUST be provided (possibly via a tunnel).
The transit provided in support of the IETF MUST be capable of providing access to the IPv4 and IPv6 default free zones without the imposition of content filtering (e.g., URL, Site, application, port, or DPI based filtering).
The primary link MUST support BGP peering, and the backup link SHOULD support BGP peering.
Routing MAY be configured to allow the simultaneous usage of the bandwidth of both the primary and backup links.
Access to research networks, like those that are part of Internet 2, MAY be provided on one of the external links.
AS Numbers MAY be supplied by the network provider. If not, the network provider MUST use the AS Numbers provided by IETF.
The network provider MUST provide at least a /19 of provider independent public IPv4 space or allow the IETF to advertise their own space.
The network provider MUST provide at least a /32 of LIR public IPv6 space or allow the IETF to advertise their own space.
If providing access space, the network provider MUST provide proper IP address delegation for DNS reverse lookups.

3. Meeting Facility

The facility SHOULD have as much physical separation as possible in the meeting room area to improve the RF environment. In addition, the facility SHOULD avoid using airwalls and other partitions with low RF attenuation in the 2.4Mhz spectrum between meeting rooms.
The facility SHOULD provide a RF environment in all meeting rooms (as identified by the Secretariat), common gathering spaces around the meeting rooms, the registration area, and the terminal room that has a reasonable noise floor in the 2.4Mhz spectrum.
The meeting facility SHOULD have installed network cabling that can be used to deploy the network infrastructure.
The meeting facility SHOULD provide the network installation team with 24 hour access to key telecom spaces. The meeting facility MUST provide the network installation team with access to key telecom spaces from one hour prior to the beginning of sessions to one hour after the end of sessions and 9am to 5pm daily during the setup period.
All locations for network gear, with the exception of wireless APs, MUST be secure.
If wireless will be used for an external link then access to the roof or installed location MUST be provided.
The meeting facility MUST have adequate ventilation to support the equipment rooms and the terminal room.
The meeting facility MUST have adequate power available to support the equipment required to support the network infrastructure and its users. This may include 110v/220v requirements in technical closets, roof locations, and various public and back-of-the-house areas.
The meeting facility The meeting facility SHOULD have UPS power available to support key network infrastructure components, including at least the core routers, core switches, and hardware to maintain the external links.
The meeting facility MUST provide sufficient power in all meeting rooms to handle the projected load from users' laptops, using 100% congruency between the projected number of attendees in each meeting room and the number of laptop users and projecting 70 watts of power usage per laptop.

4. Internal Network

Wired Ethernet connections (network drops) MUST be provided in all the locations used for meeting room audio distribution for the purposes of audio recording and transmission.
Wired network drops MUST be provided to the registration desk.
The network SHOULD have separate VLANS for wired (primarily terminal room and audio) and wireless traffic.
The network MUST NOT prohibit end-to-end and external connectivity for any traffic (no limiting firewalls or NATs).
The network SHOULD have mechanisms for detecting and silencing rogue servers (DHCP, IPv6 RA's, etc)

5. Terminal Room or equivalent

Terminal Room or equivalent A terminal room MUST be provided. This terminal room MAY be a single room or distributed sites in reasonable proximity to the meeting rooms.
The terminal room MUST provide Ethernet 10/100 connectivity with RJ-45 connectors (approximately 100-150 drops required). (note: this number should be revised based on terminal room usage statistics)
The terminal room SHOULD provide a small number of desktop or laptop computers for emergency use by attendees (minimum application requirements are web browsing, word processing, presentation production, and printing capability).
The terminal room SHOULD have 24 hour access. This access SHOULD include security, but it MAY not include a 24 hour staffed help desk.
The IETF users MUST have access to the terminal room from one hour prior to the beginning of sessions to one hour after the end of sessions.
The terminal room MUST provide at least two network connected enterprise class printers. These printers SHOULD have duplex capability.
A color printer MAY be provided.
The terminal room MUST have a manned help desk from one hour prior to the beginning of sessions to one hour after the end of sessions. The help desk provides technical assistance to attendees, provides one potential interface to the trouble ticket system (see next requirement), and maintains the printers.
The network supplier SHOULD provide a trouble ticket system to track attendee network issues. This trouble ticket system SHOULD be accessible to the help desk staff in addition to NOC staff.
Power strips MUST be provided in the terminal room.
Power strips MAY be provided in common gathering areas (desirable).
The terminal room MUST have physical security (guards) during operating hours.

6. Wireless

The network MUST provide 802.11b coverage in all meeting rooms (as identified by the Secretariat), common gathering spaces around the meeting rooms, the registration area, and the terminal room.
The network SHOULD provide 802.11b coverage in additional common spaces in the meeting venue. The lobby, bar, restaurant, and most commonly used hallways of the primary meeting hotels, SHOULD also be provide 802.11b access.
The network SHOULD provide 802.11g in all the spaces identified above.
The network SHOULD provide 802.11a coverage in as many of the above identified spaces as possible focusing on the spaces with the highest user density first (e.g. plenary meeting room).
The network design MUST anticipate 100% congruency between the projected number of attendees in each meeting room and the number of wireless network users (historical utilization in excess of 1000 simultaneous wireless users has been observed during a plenary session).
The network SHOULD provide separate SSIDs for 802.11b and 802.11a networks.
The network MUST provide fully open (unsecured) wireless access.
The network MAY provide additional secured (WEP, 802.11i, WPA) wireless access.
There SHOULD be mechanisms for identifying and silencing rogue Wireless Access Points.

7. Services

The network MUST provide redundant DHCPv4 servers.
The network SHOULD provide DHCPv6 service.
The network MUST provide local redundant DNS servers.
The network SHOULD provide NTP.
Printers MUST support IPP and SHOULD support LPR and Windows printing.
The network MUST provide a SMTP server providing relay services for the IETF network.
The network SHOULD provide a full on-site mirror of the RFC and I-D directories.

8. Network Monitoring

The network MUST provide sufficient monitoring to ensure adequate network availability and to detect faults before they impact the user experience.
The network SHOULD provide some visibility into the state of the network for attendees (e.g. public graphs of network utilization, number of wireless associations, etc.).
The network MUST collect data for future use in scaling IETF meeting network requirements. Minimum required metrics include bandwidth utilization (average and peak) for each external connection and user density per AP and radio.
The network provider SHOULD provide SNMP read-only access to the network devices to individuals as identified by the Secretariat for network management and planning purposes.

9. Miscellaneous Requirements

The network provider SHOULD maintain spares of critical network components on-site.
Attendees SHOULD be notified of power connector requirements well in advance of the meeting via both the IETF meeting web page and the IETF- announce mailing list.
A document MUST be provided to attendees detailing on-site network configuration information, including wireless configuration details, services available (e.g. printing, SMTP), instructions on how to report network issues (e.g. trouble ticket system interface instructions), etc. Initial versions of this information SHOULD be provided in advance of the meeting.
The network provider MUST NOT view the IETF network as an experimental facility at the risk of impacting the IETF attendee experience. (Do not experiment with his/her favorite pet technology.)
The network provider SHOULD have attended at least one prior IETF to observe the IETF network deployment and operation.
The network provider SHOULD supply the IETF network design to an IETF technical review team for comments.

10. Acknowledgements

These requirements are born out of the pain and experience of past hosts and volunteers. Contributors of particular note are (in no particular order):

Jim Martin
Karen O'Donoghue
Chirs Elliott
Joel Jaeggli
Lucy Lynch
Bill "wej' Jensen
Chris Liljenstoipe
Bill Fenner
Hans Kuhn

References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

This is an archived webpage. For current information about the IETF administrative arrangements, see the IETF Administration LLC website.

Abstract