1 / 24

Effectively and Efficiently Managing the Transition to IPv6

Effectively and Efficiently Managing the Transition to IPv6. Date: 05/08/06 Version 1.0 . IPv6 Transition Agenda. OMB Memorandum, Support & Guidance Network Architecture Definitions & Models The NASA IPv6 Transition Approach The 4 Phases of NASA’s IPv6 Transition project

posy
Download Presentation

Effectively and Efficiently Managing the Transition to IPv6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Effectively and EfficientlyManaging the Transitionto IPv6 Date: 05/08/06 Version 1.0

  2. IPv6 Transition Agenda • OMB Memorandum, Support & Guidance • Network Architecture Definitions & Models • The NASA IPv6 Transition Approach • The 4 Phases of NASA’s IPv6 Transition project • Project Formulation & Approval (Phases 1 & 2) • Requirements Gathering & Workflow Analysis • Phase 3 – Architecture and Design • Phase 4 - Implementation, Test & Acceptance • IPv6 Challenges

  3. [ Please read the notes section for more detail ] OMB Memorandum 05-22 Instructionto Agencies • By November 15, 2005 • Identify an IPv6 agency lead • Complete 1st inventory of IP-aware hardware devices in network backbone • By February 28, 2006 • Develop a network backbone transition plan for IPv6 • Complete an IPv6 progress report • By June 30, 2006 • Complete 2nd inventory of IP-aware applications and peripherals with dependencies on network backbone • Complete an IPv6 transition impact analysis • By June 30, 2008 • Complete network backbone transition to IPv6

  4. [ Please read the notes section for more detail ] Available Support to Agenciesfor IPv6 Transition • Transition Planning Guidance • Core.gov portal and collaboration space • Address-space acquisition training • Standards/guidelines development • Acquisition guidance

  5. [ Please read the notes section for more detail ] Currently Published IPv6 Guidance • Chapter I – Integrating IPv6 into EA Planning Activities (released) • Chapter II – Developing an IPv6 Transition Plan (released) • Chapter III – Governance (released) • Chapter IV – Acquisition/Procurement

  6. Definitions- LAN/MAN/WAN Model Wikipedia • LAN: • A Local Area Network (LAN) is a computer network covering a small local area, like a home, office, or small group of buildings such as a home, office, or college. • MAN: • Metropolitan Area Networks (MAN) are large computer networks usually spanning a campus or a city. They typically use wireless infrastructure or optical fiber connections to link their sites. For example, a university or college may have a MAN that joins together many of their LANs. They could have several WAN links to other universities or the Internet. • WAN: • A wide area network or WAN is a computer network covering a wide geographical area, involving a vast array of computers. This is different from personal area networks, MANs, or LANs that are usually limited to a room, building or campus.

  7. LAN/MAN/WAN DiagramNetwork Analysis, Architecture and Design, James D. McCabe WAN MAN MAN LAN LAN LAN

  8. Definitions- Access/Distribution/Core Model Network Analysis, Architecture and Design, James D. McCabe • Access (aka “Edge”): • The Access area is closest to the users and their Applications. The Access area is where most traffic flows are sourced (start) and sinked (terminate). • Distribution: • The distribution area area is used to consolidate traffic flows. It can also source and sink flows, but the flows are usually for servers or other specialized devices. Few users connect directly to the Distribution Area. • Core (aka “Backbone”): • The core of the network is used for bulk transport of traffic. Traffic flows are not usually sourced or sinked at the core. • External Interfaces & DMZs • Aggregation points for traffic flows external to that network

  9. Access/Distribution/Core DiagramNetwork Analysis, Architecture and Design, James D. McCabe Core Distribution Distribution Access Access Access

  10. NASA IPv6 Project Approach Mandate from the Office of Management and Budget (OMB) for all agencies to implement IPv6 by June 30, 2008 • Mandate could be interpreted for Minimalist transition approach: • - The NASA WAN • - NASA Center interfaces to the WAN • - Center Networks & all IP devices based on Business Case • Mandate could be interpreted for a Moderate transition approach: • - The NASA WAN • - NASA Center interfaces to the WAN • - Center Networks & all IP devices based on Business Case • - Center Networks & all IP capable devices • Mandate could be interpreted for an Extreme transition approach: • - The NASA WAN • - NASA Center interfaces to the WAN • - Center Networks & all IP devices based on Business Case • - Center Networks & all IP capable devices • - All IP addressable devices within the control or • purview of NASA Regardless of the approach chosen, the necessary work has to be efficiently identified and managed

  11. 2 3 1 4 NASA IPv6 Project Life Cycle - 4 Phases Project Formulation and Approval Requirements Gathering Requirements And Workflow Analysis Implementation, Test, and Acceptance Architecture And Design

  12. Project Formulation And Approval Project Formulation & Approval The 7 steps of the Project Formulation and Approval process are the sub-steps to complete the first two (1 & 2) phases of the IPv6 Project Life Cycle. 7. Requirements 1. Project Initialization 2. High-Level Information 6. Objectives 5. Problem Statements 3. Stakeholder Identification 4. Project Seed

  13. Project Formulation & Approval The 7 Project Formulation and Approval steps can be accomplished with considerable overlap Between them. They do not occur in a strictly serial fashion 1. Initialization Select program Executive, Project Manager and Requirements Manager. They will then develop the full IPv6 team, determine project Identification, and designate/create the collaboration and data collection points. 2. High-Level Information Project leadership leads the development project description, scope, objectives, operating principles, requirements, goals, deadlines to accept problem statements, and baseline terms/definitions and high-level project timeline for completion. 3. Stakeholder Identification Project leadership will lead the selection of project stakeholders to include executives, financial managers, technical representatives and others as necessary. Stakeholders will review the project documentation, review problem statements and make recommendations.

  14. Project Formulation & Approval(Continued) 4. Project Seed It is usually necessary to develop a set of initial problem statements, objectives and requirements in order to kick off the project and germinate stakeholder interaction. Project leadership will formulate and provide these project “Seeds” to the project community. 5. Problem Statements These are the set of issues, vetted by the stakeholders, to be resolved by project completion. The Objectives will map to the problem statements and the project requirements will map to the objectives. Thus the requirements map a clear line of sight relevancy to the problem statements. 6. Objectives These provide detailed, specific areas to be addressed in support of project problem statements. These are reviewed by the stakeholders and the project community. 7. Requirements These are the most specific and detailed items to be addressed in support of the objectives and problem statements. Each requirement must have clear and achievable metrics.

  15. Architecture & DesignTransition Plan All devices will eventually become IPv6 but this may take decades. In the meantime, we must transition to some level by June 30, 2008 Transition Plan Considerations: • NASA will need to interface/communicate with newly emplaced NASA and Non-NASA devices that are allocated only IPv6 Addresses. • NASA will need to communicate with NASA and Non-NASA devices that continue to operate on the old, IPv4 standards. • NASA needs to provide transport for devices developed to only operate in IPv6 mode.

  16. Architecture & DesignTransition Plan (continued) NASA Objective: Establish basic IPv6 capability in network devices located at NASA peering points, WAN backbone, and Center LAN backbones. Basic IPv6 capability is defined here as being able to transport and route in dual-stack (IPv4 and IPv6) mode, and that all devices that are configured in dual-stack mode must be able to interoperate with each other. DEADLINE: June 30, 2008

  17. Architecture & DesignTransition Plan (continued) 6 Major Steps to Meet NASA Objective • Define the sets of network devices that constitute NASA Peering Points, WAN Backbone, and Center LAN Backbones. The most challenging area will be Center LAN Backbones. • Determine the current level of IPv6 capability for each set of network devices. • Develop a risk assessments of operating in dual-stack mode and IPv4 to IPv6 translation. • Upgrade or purchase network devices as necessary to bring each set up to basic IPv6 capability as described above. • Demonstrate IPv6 routing, transport, and interoperability across NASA Peering Points, WAN Backbone, and Center LAN Backbones. • Evaluate the effectiveness and requirements of, and issues with, IPv4 to IPv6 translation.

  18. IPv6 Challenges • Available Budget & Time • Gathering Accurate Information • IP addresses that only have local significance and are not advertised outside their local networks • Devices with hardwired addresses • Important architecture devices that are not, and will never be, IPv6 capable (Security Firewalls for example) • Variance across the agency in capabilities as budget becomes available

  19. DC CIEF CIEF Midwest 2.5 Gbps lambda GRC SONET OC48 (2.5 Gbps) SONET OC12 (622 Mbps) SONET OC3 (155 Mbps) ARC JPL HQ Core Lambda Services CIEF Bay DFRC LRC CIEF South Central MSFC GSFC JSC CIEF South East WSC WSTF SSC MAF KSC MAF Architecture & Design“To-Be” Mission Support Backbone (WANR) CIEF – Carrier Independent Exchange Facility DC – District of Columbia Midwest – Chicago Bay – San Francisco South Central – Dallas South East - Atlanta

  20. Public Internet Architecture & Design“As-Is” IP Center Architecture (PIP/SIP) LAN – Local Area Network WAN – Wide Area Network Gigabit Ethernet NISN ATM Backbone Fast Ethernet OC-3 OC-12 Offsite location As needed ATM Switch Addresses from PIP passed to Public internet as needed PIP Core Router Offsite location (“tail circuit”) Router SIP Core Router Failover Switch Center LAN Router Center Campus NASA Data Center Integration Router Peering Router

  21. Public Internet Architecture & Design“To-Be” IP Center Architecture (PIP/SIP) Gigabit Ethernet Fast Ethernet OC-3 WANR Optical Core OC-12 MSPP As needed MSPP – Multi-Service Performance Platform These Key Devices will be upgraded to IPv6. All Others will be based on a Business Case. High Performance Router (HPR) NetOptics Fiber Tap Offsite location Addresses from PIP passed to Public internet as needed PIP Core Router Offsite location (“tail circuit”) Router SIP Core Router Failover Switch Center LAN Router Center Campus NASA Data Center Integration Router Peering Router

  22. Architecture & Design: Potential “To-Be” IP Network Model Architecture “To-Be” PIP/SIP Architecture HPR – High Performance Router MSPP – Multi-Service Performance Platform Everything shown in this Architecture diagram is either Optical or will be upgraded to native IPv6 in the NASA IPv6 transition plan HPR – High Performance Router MSPP – Multi-Service Performance Platform

  23. Implementation, Test And Acceptance • Phased Implementation plan as time and • budget allow • Lab and bench testing wherever possible. • Network testing at most available hours • Test each segment twice before going live • Accept only after thorough, documented testing.

  24. Questions ?? • Dr. John McManus – • NASA Chief Technology Officer (CTO) NASA Chief Enterprise Architect (CEA) • NASA Deputy Chief Information Officer (DCIO) • ESMD Chief Architect • John.W.McManus@nasa.gov • Phone: 202.358.1802 • Ken Griffey – • NASA Deputy Chief Enterprise Architect • NSSC Chief Enterprise Architect • Ken.Griffey@nasa.gov • Phone: 228.813.6209

More Related