UDP위의 L5에서 돌아감.
※ 라우터도 L4,L5 존재한다. user pkt은 L3까지만 거쳐가고 RIP control msg는 L5까지 올라간다.
DV 알고리즘: metrix=hop count (max=15hop)
→ 16이 오면 infinite로 인식.
30초마다 정보 주고받는다.
ip 위에 바로 올라감.
다익스트라 알고리즘 사용.
metrix based on type of service
two level hierarchy: 토플로지 정보 다 알려주기 힘드니까 AS 안에 여러 area 두고 그 안에서만 브로드케스트
area border router: ABR
backbone router: ABR들을 연결
AS boundary router: ASBR
backbone area는 항상 area 0이고, 이 area에선 DV 알고리즘이라서 loop free 토플로지로 짜야함
ASBR은 learn하고 propagate(advertise)(나한테 forward해라..)
inter AS routing 또는 inter domain routing 프로토콜로 불리며 ISP들을 연결. internet backbone에서 많이 쓰인다. policy based routing!
path vector routing protocol- 라우팅 루프 방지 위해 거쳐가는 AS들의 리스트를 적음
classless inter domaint routing- 클래스 A,B..이런거 안함
incremental updates-TCP 세션 맺고 나서 변화 있을 때만 advertise.
peer끼리 정보 주고받는다.
다른 AS끼린 eBGP TCP 세션 (policy 기반. 직접 연결)
같은 AS 안에선 iBGP TCP 세션.
교과서엔 fully meshed 라고 되어있는데 실제로는 ASBR하고만 다 연결되면 된다고 한다. 단 루프 방지위해 ASBR이 하나 하나 직접 연결해서 알려줌!
eBGP: learn
iBGP: propagate
tcp 위에서 돌아감.
OPEN: ASN 주고받고 eBGP인지 iBGP인지 판단
UPDATE: 새로운 path
kEEPALIVE: tcp 세션 유지 위해..
NOTIFICaTION: report (ex:루프있는걸 왜알려줌?)
BGP route=(dest prefix,path attribute to the dest)
dest prefix:dest subnet의 정보
path attribute
import policy: 정보를 learn 했으니 내 AS에서 나가는 traffic이 생기겠네
export traffic: 정보 줬으니까 incoming traffic 받아들일게! (싫었으면 애초에 advertisement 안했어야)
루트 여러개일 때 고르는 우선순위
inter은 policy 중심. intra는 성능 중심
ICMP 메세지는 ip datagram 안에서 carried(ip 바로 위에 올라감!)
ICMP는 호스트와 라우터가 에러 리포트하고 그에대한 request/reply를 주고받는데 쓰이는 프로토콜.
※ msg에 대한 error report는 그 msg를 처음 만든 애한테 보낸다!
ICMP message: type , code plus first 8 byte
ex)
type code description
(3,3,dest port unreachable)
(11,0,TTL expired)
ICMP msg 쓰는 라우터는 trace router
※record RTT → src가 TTL 1로 해서 UDP segment 보낸다. → 다음 라우터는 trop 한 다음에 type11, code0 ICMP 메세지를 src에 보낸다. → src는 record하고 RTT=2로 해서 보낸다.
(한 홉 딜레이 같은 걸 재는데 씀)
nw control app(라우팅+α)은 정교한 s/w로 프로그래밍 된다. 이렇게 하기 위해 high level api(north bound api)를 서버에서 쓴다. 근데 이 high level api들은 user traffic이 지나다니는 nw device로부터 멀고 분리되어있다.
control plane과 data plane이 분리되어 있다.
traditional 라우터는 어플, OS, HW등등을 한 회사의 제품으로 통일해서 번들로 사야했음. 불편!
→ SDN을 이용하면 따로따로 구매하기 가능해짐
몇몇 라우터들을 컨트롤하는 logically centralized control plane. 여러 서버가 마치 하나인것처럼 동작
이렇게 하는 이유는?
1. easier nw management
2. programmable router(프로그래밍 더 쉽다.)
3. open implementation of control plane
a. network control palne
b. SDN controller
c. SDN-controlled switch
c번 위치.
fast,simple commodity switch(in hw)
nw control application이 계산한 switch flow를 전달 받음. controller와 소통하고 switch control 하기 위한 southbound api(ex:openFlow)
※ flow table은 SDN controller가 계산하는 것이 아님! nw control application이 계산한것.
a번 위치.
'brain' of control: northbound api 이용해 계산
unbundled: can be provided by 3rd party (다 다른 회사 제품으로 구성해도 됨!)
b번 위치.
기존 라우터의 경우, 돌아서 가고 싶으면 그렇게 되도록 링크 코스트를 조정해야 했다. 하지만 SDN은 nw control applciation에 있는 sw 덕분에 돌아가기가 가능하고, load balancing 또한 가능하다.
operate between controller and switch. TCP 사용.
3가지 openFlow msg class