DNMTT ‐‐ NASPI WGDNMTT  NASPI WGFeb 20, 2013   

An InterNut Looks at NASPInet

Bob BradenBob Braden

USC Information Sciences Institute

Marina del Rey CAMarina del Rey, CA

• Last month was the 30th anniversary of theLast month was the 30 anniversary of the Internet.

• Is the Internet experience relevant to the• Is the Internet experience relevant to the design of NASPInet?

N dl i i h h l ld b• Needless re‐inventing the wheel would be costly.

2/20/2013 DNMTT Feb2913 2

Internet Protocol Suite (IPS):d lGuiding Principles

1 Interoperability is essential1. Interoperability is essential

2. Don’t over‐optimize

3 i i l ibl (b i l )3. Keep it as simple as possible (but no simpler)

4. Obey End‐to‐End principle whenever possible

5. Use distributed control

2/20/2013 DNMTT Feb2913 3

1. Interoperabilityp y

• Specify enough (but not more) so twoSpecify enough (but not more) so two conforming implementations will interoperate correctly out of the boxcorrectly, out of the box.– Allow multiple vendors

Allow innovative implementations– Allow innovative implementations

• IETF Standardization rules: require at least 2• IETF Standardization rules: require at least 2independent interoperable implementations.

2/20/2013 DNMTT Feb2913 4

… Interoperability… Interoperability

• Before you accept any NASPInet proposal:Before you accept any NASPInet proposal: “show us the bits on the wire.”

• So vendor A and vendor B can interoperate• So vendor A and vendor B can interoperate with different implementations.

C f fi l NASPI d i• Comment: exposure of final NASPInet design in the IETF might save a lot of trouble in the llong run.

2/20/2013 DNMTT Feb2913 5

2. Don’t Over‐optimize2. Don t Over optimize

• Be willing to sacrifice some efficiency to gainBe willing to sacrifice some efficiency to gain flexibility & uniformity– The problem will change– The problem will change

– The technology will rapidly evolve

E “W d l i t t k l• Eg “We can develop our own internetwork layer protocol that will be more efficient that IP [for our specific case] ”specific case].

–BAD IDEA!! 

2/20/2013 DNMTT Feb2913 6

NASPInet ExampleNASPInet Example

• Two quite different NASPInet functions:Two quite different NASPInet functions:1. Delivery of PMU data streams

2 Closed loop control2. Closed loop control

• Could build two different NASPInets, one ti i d f h f tioptimized for each function.

• Probably a BAD IDEA (but not certain).

2/20/2013 DNMTT Feb2913 7

3. Simplicity3.  Simplicity

• Simplicity ~ elegance in protocol designSimplicity    elegance in protocol design

• Complexity goes with:li– ugliness

– unmaintainability

– non‐interoperability

• Unfortunately, all protocols tend to accrete features … !

2/20/2013 DNMTT Feb2913 8

4. End‐to‐End Principle4.  End to End Principle

• Converse of the telephone system ‐‐Converse of the telephone system – Phones: smart network, dumb terminals

Internet: smart terminals dumb network– Internet: smart terminals, dumb network

• Dumb network adaptable to new applications– Minimal function in internetwork:  => IP

– No per‐flow state in routers

2/20/2013 DNMTT Feb2913 9

… End‐to‐End Principle… End to End Principle

• Those who would violate the E2E principleThose who would violate the E2E principle have to make a strong case in the IETF. – IP multicast violates E2E principle– IP multicast violates E2E principle

– RSVP  and Integrated Service violate E2E principle

GridStat violates E2E principle– GridStat violates E2E principle

2/20/2013 DNMTT Feb2913 10

5. Distributed Control5. Distributed Control

• Avoid single points of failureAvoid single points of failure

• Avoid implosion points

• Example: – GridStat does pub/sub centrally

– IP MC, RSVP do pub/sub in distributed fashion

2/20/2013 DNMTT Feb2913 11

Untrue Rumors about the IPSUntrue Rumors about the IPS

• IPS cannot stream real‐time dataIPS cannot stream real time data• See VoIP, Skype

• IPS has no QoS mechanisms• IPS has no QoS mechanisms• See Diff Service, Integrated Service

• IPS cannot bound E2E latency• IPS cannot bound E2E latency• See  Guaranteed Service under Int Serv

IPS t d ti• IPS cannot do resource reservation• See RSVP 

2/20/2013 DNMTT Feb2913 12

Fact: Limited deploymentFact: Limited deployment

• Backbone providers typically provide onlyBackbone providers typically provide only basic best‐effort service

• But some corporate intranets provide IP MC• But some corporate intranets provide IP MC, diff‐serv, int‐serv, resource reservations, …

2/20/2013 DNMTT Feb2913 13

Some Common FallaciesSome Common Fallacies

• The IPS* cannot stream real time dataThe IPS  cannot stream real time data– Have you used Skype or VoIP lately?

• The IPS has no QoS provisions• The IPS has no QoS provisions– See Differentiated Services, Integrated Services

• The IPS cannot provide bounded E2E delay• The IPS cannot provide bounded E2E delay– See Guaranteed Service under Integrated Services

Th I t t t d ti• The Internet cannot do resource reservations– See RSVP                                           *Internet Protocol Suite

2/20/2013 DNMTT Feb2913 14

Important IssuesImportant Issues

In packet switching important issues include:In packet switching, important issues include:

• Naming and Addressing

C i• Congestion

• Fragmentation• Why aren’t you worried about fragmentation?

• Buffering

• Store‐and‐forward delays

2/20/2013 DNMTT Feb2913 15

Naming and AddressingNaming and Addressing

• 61850 requires a 128 bit unique name for61850 requires a 128 bit unique name for every hardware box.

• A new name space => questions• A new name space => questions– Who allocates names?

H i i bi f di ib d ll i ?– How partition bits for distributed allocation?• Suggest: Use convenient /n notation from IP addr

N d DNS lik di i• Need new DNS‐like directory service to map these hardware IDs to IP addresses.

2/20/2013 DNMTT Feb2913 16

• But if every box already has 128 bit unique IPBut if every box already has 128 bit unique IP address, do we really need a new name space at all?at all?

2/20/2013 DNMTT Feb2913 17

NASPInetNASPInet

• Will be a (more or less) crisply defined subset of ( ) p ythe Internet.– Completely isolated network?  Never happen ‐‐“Backdoor” Internet connections inevitable– “Backdoor” Internet connections inevitable.

• Built on Internet protocol suite (IPS):– IP at internetwork layerIP at internetwork layer – Some transport protocol (UDP, TCP, SCTP …)

• That positions NASPInet in:– the Application layer (eg IP MC)‐‐ or in middleware layer (eg GridStat)

2/20/2013 DNMTT Feb2913 18

The Isolation MythThe Isolation Myth

• “If we build a new network isolated from theIf we build a new network isolated from the Internet, we can get precisely the service we need and avoid many security problems”need and avoid many security problems

• It never worksE d I t t b k d f t– E.g., need Internet back doors for management, configuration, diagnosis, …

Even with only one 300 baud modem connection– Even with only one 300 baud modem connection, bad guys can get in and take over.

2/20/2013 DNMTT Feb2913 19

Proposed NASPInet‐P ArchitecturesProposed NASPInet P Architectures

• IP MC – Myrda et alIP MC  Myrda et al– Network layer MC, TA* at dest

• Chained PDCs• Chained PDCs – App layer or network layer MC

– TA at intermediate PDCs and dest

• GridStat ‐‐ Bakken et al– Middleware approach

*Time aligng

2/20/2013 DNMTT Feb2913 20

• Can we choose one of these?Can we choose one of these?

• Must we choose one?

h i d d h i l ?• What input do we need to choose wisely?

2/20/2013 DNMTT Feb2913 21

Some OpinionsSome Opinions

• We are underestimating the rapidity ofWe are underestimating the rapidity of evolution in communication software and hardwarehardware – Transformers can last 50 years, but specifying a 15 year lifetime for NASPInet seems foolishyear lifetime for NASPInet seems foolish

• Should think of a PG as a set of functions, not as a deviceas a device.

• PG currently has too many functions, is too l i f tcomplex, in fact.

2/20/2013 DNMTT Feb2913 22

More OpinionsMore Opinions

• The “Data Bus” is an unfortunate andThe  Data Bus  is an unfortunate and misleading metaphor. Should be cloud.

• Maybe we are underestimating the ability of li i b ild dapplication builders to accommodate 

lost/delayed data.– Buffering is cheap

– Physical system has lots of inertia

2/20/2013 DNMTT Feb2913 23

Danger Areas for NASPInetDanger Areas for NASPInet

• NASPInet dynamics will be similar to Internet’sNASPInet dynamics will be similar to Internet s

• Rapid technology change

Ch i bl• Changing problem space– See: “An Internet‐Inspired Electricity Grid”, IEEE Spectrum, 12‐14, Jan 2013.

• Success disaster

2/20/2013 DNMTT Feb2913 24

Robust, Interoperable ImplementationImplementation 

• Postel Principle: “Be conservative in what you send and liberal in what you receive ” [RFC1122]send and liberal in what you receive.  [RFC1122]

2/20/2013 DNMTT Feb2913 25

Thank You

2/20/2013 DNMTT Feb2913 26