Network Protocols UNIT III INTERNETWORK PROTOCOLS Routing Protocols

Network Protocols UNIT III- INTERNETWORK PROTOCOLS

Routing Protocols z Routing Information y. About topology and delays in the internet z Routing Algorithm y. Used to make routing decisions based on information

Autonomous Systems (AS) z Group of routers z Exchange information z Common routing protocol z Set of routers and networks managed by signle organization z A connected network y. There is at least one route between any pair of nodes

Interior Router Protocol (IRP) z Passes routing information between routers within AS z May be more than one AS in internet z Routing algorithms and tables may differ between different AS z Routers need some info about networks outside their AS z Used exterior router protocol (ERP) z IRP needs detailed model z ERP supports summary information on reachability

Application of IRP and ERP

Border Gateway Protocol (BGP) z For use with TCP/IP internets z Preferred EGP of the Internet z Messages sent over TCP connections y. Open y. Update y. Keep alive y. Notification z Procedures y. Neighbor acquisition y. Neighbor reachability y. Network reachability

BGP Messages

BGP Procedure z Open TCP connection z Send Open message y. Includes proposed hold time z Receiver selects minimum of its hold time and that sent y. Max time between Keep alive and/or update messages

Message Types z Keep Alive y. To tell other routers that this router is still here z Update y. Info about single routes through internet y. List of routes being withdrawn y. Includes path info x. Origin (IGP or EGP) x. AS_Path (list of AS traversed) x. Next_hop (IP address of boarder router) x. Multi_Exit_Disc (Info about routers internal to AS) x. Local_pref (Inform other routers within AS) x. Atomic_Aggregate, Aggregator (Uses address tree structure to reduce amount of info needed)

Uses of AS_Path and Next_Hop z AS_Path y. Enables routing policy x. Avoid a particular AS x. Security x. Performance x. Quality x. Number of AS crossed z Next_Hop y. Only a few routers implement BGP x. Responsible for informing outside routers of routes to other networks in AS

Notification Message z Message header error y. Authentication and syntax z Open message error y. Syntax and option not recognized y. Unacceptable hold time z Update message error y. Syntax and validity errors z Hold time expired y. Connection is closed z Finite state machine error z Cease y. Used to close a connection when there is no error

BGP Routing Information Exchange z Within AS, router builds topology picture using IGP z Router issues Update message to other routers outside AS using BGP z These routers exchange info with other routers in other AS z Routers must then decide best routes

Open Shortest Path First (1) z OSPF z IGP of Internet z Replaced Routing Information Protocol (RIP) z Uses Link State Routing Algorithm y. Each router keeps list of state of local links to network y. Transmits update state info y. Little traffic as messages are small and not sent often y. RFC 2328 z Route computed on least cost based on user cost metric

Open Shortest Path First (2) z Topology stored as directed graph z Vertices or nodes y. Router y. Network x. Transit x. Stub z Edges y. Graph edge x. Connect two router x. Connect router to network

Sample AS

Directed Graph of AS

Operation z Dijkstra’s algorithm (Appendix 10 A) used to find least cost path to all other networks z Next hop used in routing packets

Integrates Services Architecture z Changes in traffic demands require variety of quality of service z Internet phone, multimedia, multicast z New functionality required in routers z New means of requesting Qo. S z ISA z RFC 1633

Internet Traffic z Elastic y. Can cope with wide changes in delay and/or throughput x. FTP sensitive to throughput x. E-Mail insensitive to delay x. Network Management sensitive to delay in times of heavy congestion x. Web sensitive to delay z Inelastic y. Does not easily adapt to variations ye. g. real time traffic

Requirements for Inelastic Traffic z Throughput z Delay z Jitter y. Delay variation z Packet loss z Require preferential treatment for certain types of traffic z Require elastic traffic to be supported as well

ISA Approach z Congestion controlled by y. Routing algorithms y. Packet discard z Associate each packet with a flow y. Unidirectional y. Can be multicast z Admission Control z Routing Algorithm z Queuing discipline z Discard policy

ISA Components

Token Bucket Traffic Specification z Token replenishment rate R y. Continually sustainable data rate z Bucket size B y. Amount that data rate can exceed R for short period y. During time period T amount of data sent can not exceed RT + B

Token Bucket Scheme

ISA Services z Guaranteed y. Assured data rate y. Upper bound on queuing delay y. No queuing loss y. Real time playback z Controlled load y. Approximates behavior to best efforts on unloaded network y. No specific upper bound on queuing delay y. Very high delivery success z Best Effort

Queuing Discipline z Traditionally FIFO y. No special treatment for high priority flow packets y. Large packet can hold up smaller packets y. Greedy connection can crowd out less greedy connection z Fair queuing y. Queue maintained at each output port y. Packet placed in queue for its flow y. Round robin servicing y. Skip empty queues y. Can have weighted fair queuing

FIFO and Fair Queue

Resource Reservation: RSVP z Unicast applications can reserve resources in routers to meet Qo. S z If router can not meet request, application informed z Multicast is more demanding z May be reduced y. Some members of group may not require delivery from particular source over given time xe. g. selection of one from a number of “channels” y. Some group members may only be able to handle a portion of the transmission

Soft State z Set of state info in router that expires unless refreshed z Applications must periodically renew requests during transmission z Resource Re. Ser. Vation Protocol (RSVP) z RFC 2205

RSVP Goals z Ability for receivers to make reservations z Deal gracefully with changes in multicast group membership z Specify resource requirements such that aggregate resources reflect requirements z Enable receivers to select one source z Deal gracefully with changes in routes z Control protocol overhead z Independent of routing protocol

RSVP Characteristics z Unicast and Multicast z Simplex z Receiver initiated reservation z Maintain soft state in the internet z Provide different reservation styles z Transparent operation through non-RSVP routers z Support for IPv 4 and IPv 6

Data Flow Concepts z Session y. Data flow identified by its destination z Flow descriptor y. Reservation request issued by destination y. Made up of flowspec and filterspec y. Flowspec gives required Qo. S y. Filterspec defines set of packets for which reservation is required

Treatment of Packets

RSVP Operation

RSVP Message Types z Resv y. Originate at multicast receivers y. Propagate upstream through distribution tree y. Create soft states within routers y. Reach sending host enabling it to set up traffic control for first hop z Path y. Provide upstream routing information

Operation From Host Perspective z Receiver joins multicast group (IGMP) z Potential sender issues Path message z Receiver gets message identifying sender z Receiver has reverse path info and may start sending Resv messages z Resv messages propagate through internet and is delivered to sender z Sender starts transmitting data packets z Receiver starts receiving data packets

Differentiated Services z Provide simple, easy to implement, low overhead tool to support range of network services differentiated on basis of performance z IP Packets labeled for differing Qo. S using existing IPv 4 Type of Service or IPv 6 Traffic calss z Service level agreement established between provider and customer prior to use of DS z Built in aggregation y Good scaling to larger networks and loads z Implemented by queuing and forwarding based on DS octet y No state info on packet flows stored

DS Services z Defined within DS domain y. Contiguous portion of internet over which consistent set of DS policies are administered y. Typically under control of one organization y. Defined by service level agreements (SLA)

SLA Parameters z Detailed service performance y. Expected throughput y. Drop probability y. Latency z Constraints on ingress and egress points z Traffic profiles ye. g. token bucket parameters z Disposition of traffic in excess of profile

Example Services z Level A - low latency z Level B - low loss z Level C - 90% of traffic < 50 ms latency z Level D - 95% in profile traffic delivered z Level E - allotted twice bandwidth of level F traffic z Traffic with drop precedence X higher probability of delivery than that of Y

DS Octet - Code Pools z Leftmost 6 bits used z 3 pools of code points z xxxxx 0 yassignment as standards z xxxx 11 yexperimental or local use z xxxx 01 yexperimental or local but may be allocated for standards in future

DS Octet - Precedence Fiedl z Routing selection z Network service z Queuing discipline

DS Domains

DS Configuration and Operation z Within domain, interpretation of DS code points is uniform z Routers in domain are boundary nodes or interior nodes z Traffic conditioning functions y. Classifier y. Meter y. Marker y. Shaper y. Dropper

DS Traffic Conditioner

What Protocols Are Needed for IP Telephony? z Signaling protocol to establish presence, locate users, set up, modify and tear down sessions z Media Transport Protocols for transmission of packetized audio/video z Supporting Protocols for Gateway Location, Qo. S, interdomain AAA, address translation, IP, etc.

SIP is the Session Initiation Protocol z SIP is an application layer signaling protocol y create, modify and terminate sessions y two or more participants z Uses URL style addresses and syntax z Flexible transport: can use UDP, TCP, TLS, or SCTP z Uses SDP for describing media sessions: Audio, Video, realtime Text, IM, speech services, etc. z Applications include (but not limited to): Voice, video, gaming, instant messaging, presence, call control, etc. z Simple extensible protocol y Methods—Define transaction y Headers—Describe transaction y Body—SDP and other MIME content

Vo. IP in the Enterprise z. Services available to all company’s users, onsite, offsite and multi-site – toll bypass. • No telephone line required for home-workers and remote offices. • Single infrastructure for data and voice. • Effectiveness tools. • Service operation can be outsourced in a Centrex -like manner (MCI Advantage). Like with web/email, single server may host multiple domains

SIP Makes Vo. IP Easy and Interoperable z IETF development, learning from HTTP experience, leads to (eventually) excellent interoperability z Becoming an IP-Telephony operator takes complexity comparable to setting up E-mail server: y– Configure DNS y– Download and configure a SIP proxy server y– Configure supporting services: web provisioning, database back-end typically. y– Configure PSTN gateway for use with your proxy server.

SIP Architecture is Easy to Understand Directory: DNS ENUM Call Setup: SIP SDP Call Transport: RTP AAA: Radius Diameter IP Network PSTN Gateway IP Softphone

SIP Addresses are Global z SIP gives you a globally reachable address. y Callees bind to this address using SIP REGISTER method. y Callers use this address to establish real-time communication with callees. z URLs used as address data format; examples: y sip: crw@transcendental. com y sip: voicemail@iptel. org? subject=callme y sip: 17005553171@asterisk. sip. ilabs. interop. net

RTP: A Transport Protocol for Real-Time Applications z Provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. z Those services include payload type identification, sequence numbering, timestamping and delivery monitoring. z Applications typically run RTP on top of UDP

z Audio and Video Conference y. Audio and video media are transmitted as separate RTP session and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. y. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated. y. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTP packets for both sessions.

MIXER z Receives streams of RTP data packets from one or more sources, possibly changes the data format, combines the streams in some manner and then forwards the combined stream. z All data packets forwarded by a mixer will be marked with the mixer's own SSRC identifier. In order to preserve the identity of the original sources contributing to the mixed packet

Translator z Forwards RTP packets with their SSRC identifier intact z May change the encoding of the data and thus the RTP data payload type

RTP Header Payload type Timestamp SSRC identifier Sequence number

RTCP z Is based on the periodic transmission of control packets to all participants in the session and perform the following functions: yprovide feedback on the quality of the data distribution and allows one who is observing problems to evaluate whether those problems are local or global.

y. RTCP carries an identifier for an RTP source called the canonical name or CNAME. Receivers use CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video.

RTCP Packet Format z SR: Sender report, for transmission and reception statistics from participants that are active senders. z RR: Receiver report, for reception statistics from participants that are not active senders. z SDES: Source description items, including CNAME. z BYE: Indicates end of participation. z APP: Application specific functions.

RTCP Transmission Interval z RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. z In an audio conference the data traffic is inherently self- limiting because only one or two people will speak at a time, so with multicast distribution the data rate on any given link remains relatively constant independent of the number of participants. z However, the control traffic is not self-limiting. If the reception reports from each participant were sent at a constant rate, the control traffic would grow linearly with the number of participants.

z To maintain scalability, the average interval between packets from a session participant should scale with the group size. z The control traffic should be limited to a small and known fraction of the session bandwidth: y small so that the primary function of the transport protocol to carry data is not impaired; y known so that each participant can independently calculate its share. z It is suggested that the fraction of the session bandwidth allocated to RTCP be fixed at 5%

Receiver Report RTCP Packet RC Type Length SSRC of first source Fraction lost Cumulative number of packet lost Interarrival jitter Last SR Delay since last SR Report block 2 Report block 1 SSRC of packet sender