컴퓨터 네트워크 9주차

---

 

 

목적지 주소가 위 템플릿의 각각의 주소 범위에 속하면, 0, 1, 2, link interface로 보내고, 해당 범위에 속하지 않으면 3 link interface로 보낸다.

 

 

logest prefix matching은 고속 라우터 같은 경우에는, 주소를 찾을 때 한꺼번에 찾는다.

content addressable: 원 사이클 내에, 테이블 사이즈에 상관없이 해당하는 영역에 맞는 주소를 찾아서 link interface를 준다.

---

 

• switching fabric: 패킷을 인풋 버퍼로부터 적절한 아웃풋 버퍼로 이동시켜 전달해준다(transmission)

• switching rate: 패킷들이 인풋으로부터 아우풋 쪽으로 전송되는 속도. 만약에 N개의 인풋이 있으면 switching rate는 N time line rate를 갖는 게 바람직하다.

• 만약에 인풋과 아웃풋이 다르다면 N개 연결을 한꺼번에 처리할 수 있다.

 

• 최초의 라우터 세대가 사용한 방식

• input port로부터 들어온 패킷이 메인 메모리에 카피가 됐다가, output port가 결정이 되면, 해당 port로 전달.

• 메모리의 대역폭에 의해서 속도가 제한되며, input port로 들어올 때 1번, output port로 나갈 때 1번, 총 2번이 버스 크로싱이 발생한다.

• 1세대 방식이기 때문에 성능이 그리 좋지 못하다.

 

• swiching via a bus 방식은 input port와 output port 각각에 메모리(버퍼)가 있어서 input port 메모리로부터 output port 메모리로 shared bus를 통해서 전달.

• bus contention: 버스 대역폭에 의해서 스위칭 스피드가 제한된다. 1st generation router와 다른 점은 이 버스가 굉장히 고속이고, 별도의 input port memory, output port memory를 사용하기 때문에 memory crossing이 발생하는 현상을 줄일 수 있다.

• bus의 속도를 올리는 게 생각보다 어려워서 나오게 된 게 interconnection network이다.

 

• 버스의 속도(대역폭)가 제한되는 문제를 극복하기 위해 제안

• 가변 길이를 갖는 데이터 그램을 고정 길이의 셀로 input port에서 자른 다음, 이 셀을 fabric을 통해서 switch하고 output port로 나올 떄, 잘린 셀을 다시 합친다.

ㄴ

• switch fabric이 input port를 합친 것보다 느리면, input queue에서 queueing이 일어난다.

• input buffer와 output buffer를 별도로 사용하기 때문에 queueing delay와 loss가 발생한다.

• Head of the Line: queue 앞쪽에 queueing된 데이터 그램이 새로운 데이터 그램이 queueing 되는 걸 방해한다.

 

• switch fabric에서 datagram buffer로 queueing 돼서 패킷이 들어오면 link layer protocol이 실행되고 line termination(전기적 신호가 반사되지 않게 조치)

• fabric으로 부터 도착하는 속도가, 데이터 그램을 전송하는 속도보다 빠르다면 버퍼링이 필요하다.

• scheduling displine: 전송을 위해서 queue된 데이터 그램 사이에서 전송을 할 건지 정하는 규칙. 지금까지는 그냥 queue 방식(first in first out). 즉 schduling displine은 스위치에 따라서 반드시 FIFO가 아니라 다른 정책으로 전송 방식을 채택할 수 있다.

 

• 위 템플릿에서 1번과 2번이 one packet time에 어떻게 동시에 처리될 수 있었을까? → 1번 output port에 버퍼(메모리)가 있기 때문에 output port buffer에 집어넣은 것뿐이다.

• output port에 버퍼에 오버플로우가 발생하면 queueing delay와 심각하면 loss도 발생한다.

 

Overflow나 Loss가 발생하지 않으려면 어느정도의 버퍼를 준비해야 할까?

---

스케줄링이란? 링크로 전송할 다음 패킷을 결정(즉, 순서 결정)

큐에 대기 중인 패킷이 가득 찼을 때 어떤 걸 버릴까?

• tail drop: 가장 늦게 도착한 패킷 제거

• priority: 각 패킷에 매겨진 우선순위를 기준으로 패킷 제거

• random: 랜덤하게 패킷 제거(의외로 효과가 좋음)

 

priority scheduling: 버릴 때도 우선순위를 둘 수 있지만, 우선적으로 서비스해줄 패킷 결정

high priority queue에 패킷이 있으면 그 패킷들 먼저 우선적으로 처리하고, 그 다음에 우선 순위가 높은 큐에 패킷들 처리하고... 우선순위 별로 순차적으로 처리(비행기 first class, business class, economy class를 생각하면 된다. first class 승객들 먼저 다 태우고, business class 승객 태우는 것처럼...)

 

Round Robin scheduling

다양한 순위의 우선순위를 가진 패킷들이 도착할 때, first class 한 번 scheduling second class scheduling 하고(first class가 추가적으로 있더라도...), 다시 first class 한 번 schduling 하고...

 

Weighted Fair Queueing(Generalized Round Robin): 가중치를 두고 공평하게 Scheduling

각 class에 한 번씩 기회를 주는 게 아니라, 각 클래스별로 가중치를 두고, 가중치만큼의 서비스를 받게 한다. 일반적인 Round Robin 방식은 weight가 1이었다면, WFQ 방식은 이 weight가 class별로 다르다.

 

 

e.g. W_1(weight) = 3, W_2 = 1, W_3 = 2, Q1, Q2, Q3가 있다고 해보자. 위 그림을 보면 도착한 각각의 패킷 개수(위 패킷은 모두 도착했고, 처리 시간도 같다고 가정한다)을 가중치로 나눈 값을 표현하고 있다. 그럼 가장 값이 작은 P1(1/3) 패킷이 먼저 처리되고 그 다음으로 값이 작은 P8(1/2) 가 처리된다. 이런 방식으로 큐마다 다르게 부여된 가중치를 도착한 패킷 개수로 나누면 우선순위별로 서비스가 됨을 알 수 있다.

---

• routing protocol: IP Protocol에서 원하는 목적지로 갈 수 있게 적절한 경로에 대한 정보 수집 및 경로 설정(e.g. RIP, OSPF, BGP...)

• routing table에서 정보를 모으고, 모은 정보를 기반으로 forwarding table을 만들고, forwarding table을 참조해서 IP protocol header에 있는 목적지에 해당하는 forwading table entry를 찾고, fowarding table entry에 맞는 output port 쪽으로 데이터 그램 전송하는 매커니즘

 

• ver: IPv4 or IpV6

• type of service: 데이터의 타입에 따라서 차등적으로 처리하기 위해 존재(IPv4에서는 거의 사용되지 않는 필드)

• length: 데이터그램의 전체 길이(byte 단위)

• 16-bit identifier: sequence number와는 다름.

• time to live: 최대 몇 개의 라우터를 만날 때까지 목적지에 도착 못 하면 해당 패킷 폐기(즉, 목적지에 도착할 때까지 마주칠 수 있는 최대 라우터) → 루핑을 방지하기 위해 존재(동일한 라우터를 계속 돌 수 있으므로 ). 각 라우터를 지날 때마다 하나씩 감소시킴

• upper layer: payload(data) 값을 전달해줄 upper layer protocol. IP protocol의 upper protocol이면 보통 TCP나 UDP.

• options(e.g. timesatamp: 데이터그램이 생성된 시간, record route taken: 거쳐가는 라우터 주소 기록, sepcify list of routers: 방문할 라우터 리스트

 

인터넷을 사용하면서 얼마나 많은 overhead가 발생할까?

IP protocol header가 20 bytes(except for options) + TCP에서 헤더가 약 20 bytes + application layer에서 붙는 오버헤드 ⇒ 20 bytes + 20 bytes + application header

※ IP Protocol은 seqeunce number가 없으므로 reliable data transfer를 제공하지 않는다. 그래서 에러가 나면 그냥 데이터그램을 버린다.

네트워크 링크(라우터와 라우터를 연결)는 MTU(Maximum Transfer)를 가지고 있다. MTU란 해당 링크 레벨에서 처리가 가능한 사이즈(즉, 이 사이즈까지는 내 링크에서 수용 및 처리가 가능한데 이 사이즈가 넘어가면 안 돼~). 그래서 링크마다 각각의 MTU size를 가지며 MTU 사이즈는 링크마다다를 수 있다.

만약 특정 링크에 MTU 사이즈보다 큰 IP 데이터그램이 도착한다면 링크를 통과하기 위해 해당 IP 데이터그램을 MTU 사이즈에 맞게 쪼개야 한다(Fragment). 그래서 한 개의 데이터 그램이 여러 개의 데이터 그램으로 바뀌고, 최종 목적지에 도착을 하면 쪼개진 데이터 그램을 다시 재조합한다. 해당 링크만 지나고 다른 링크에서 다시 재조립해서 전송하면 되지 않나요? 라고 물을 수 있겠지만, 쪼개진 패킷이 다음 링크로 모두 도착한다는 보장이 없고 다시 쪼개질 수도 있기 때문에 최종 목적지에서 재조합해서 다음 layer로 올린다.(reassembled only at final destination)

final destination에서 IP 헤더 bit를 이용해서 쪼개진 데이터그램을 구별하고 재조합한다.

 

• fragflag = 0 → 해당 프래그먼트가 마지막

• offset = 0 → 처음 프래그먼트. (fragflag = 0 & offset = 0 → 해당 데이터그램이 처음이자 마미작 즉 쪼개지지 않은 데이터그램)

• offset 계산: 데이터 크기(payload)가 1480이면 1480 / 8을 한다. 8 byte(bit가 아니다)를 한 단위로 묶는다. 8 bytes 씩 한 묶음으로 묶는 이유는 offset field가 작기 때문에...
• 맨 위의 offset이 185이지만 0이라고 쓴 이유는 0부터 시작한다는 의미이다. 그래서 그 다음 패킷의 offset이 185로 시작한다. 왜냐하면 그 전 패킷의 offset이 0 ~ 184였기 때문에...